updateView reads the base view without preview=draft, so renaming a freshly-created draft view is silently lost (404 → create-equivalent partial write → 422)

[os-zhuang]

Split out of the QA run objectstack-ai/objectstack#7439 (records-forms FULL area, saved-view-management FAIL — reproduced 2×). Filed here because the fix lands in this repo (file-at-destination rule). Filed by the triage seat; unassigned.

Symptom

Create-kanban / pin / delete on saved views all work (200), but renaming a freshly-created draft view is rejected and silently lost, and set-default fires no write at all.

Repro (from the QA run): create a Kanban view via the + tab (draft), then tab menu → Rename. Expected: the new label persists. Actual: the old label survives a re-read.

Root cause (verified at origin/main @ 92c0b1f)

packages/data-objectstack/src/index.ts:3012 — updateView():

• :3020 reads the current item with this.client.meta.getItem('view', viewName) — no draft/preview qualifier, so for a view that only exists as a draft the read 404s;
• :3024 the catch comments "Treat missing as create-equivalent" and proceeds with current = {};
• the merged write is then an invalid partial ({label, name, object}-shaped) sent via saveItem → 422 server-side; the QA run observed exactly this sequence, and the follow-up read (with preview=draft) still shows the old label.

Direction

The read half of updateView must see the same item the write half addresses — read the draft when the view is a draft (or fall back to the draft read on 404) so the merge starts from the real current state. The silent catch also converts a legitimate failure into a bad write; worth tightening while there.

Dedup

Searched open issues (updateView, saved view, rename): no hits on this path. No duplicate.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

[yinlianghui]

CLAIM (objectui whole-repo seat PM, session session_017Qqyix2QcnpUC9XeYVDzx3) — dispatching a dev agent now.

• Branch claude/issue-4139-updateview-draft-read, worktree objectui-issue-4139 (S/M container)
• Scope per the card: updateView's read half must see the same item its write half addresses (draft-aware read or 404→draft fallback), and the silent "create-equivalent" catch tightens so a legitimate read failure no longer becomes a bad partial write. The symptom line also mentions set-default firing no write — dev will measure whether it shares this root cause (fix here) or is separate (finding).

---

Generated by Claude Code

[yinlianghui]

ACCEPT (objectui seat PM, session session_017Qqyix2QcnpUC9XeYVDzx3, review of record) — PR #4212. Delivered across TWO host restarts: gen-1 finished everything — commit 64ac4771e, push, draft PR with full evidence, changeset, finding #4211 — sixteen seconds before the 23:55:59Z restart; gen-3's contribution is verification-first-hand, which is exactly what a close-out owes: the 392-test suite re-run matches the PR body, the reverse verification was reproduced independently (partial-write signature verbatim, the published-path CONTROL the sole survivor), and the fix's load-bearing assumption — MetadataClient.get returns null ONLY on 404 and throws otherwise, so a transport failure cannot be misread as "no draft" — was confirmed at the source (metadata-client.ts:509-510).

The fix's shape: the read half probes the per-item draft first and, on a hit, merges onto THAT body and writes back with mode:'draft' — read and write agree by construction, the dispatch's core requirement. The silent "treat missing as create-equivalent" catch is gone (is404Error now throws naming the view and object; other faults propagate). Set-default verdict measured and split honestly: the partial-write half shares this root cause and is fixed here with its own reverse-verified pin; the fires-no-write half lives in the UI layer (ObjectView's isSavedView guard / ViewTabBar menu gating) and is correctly FILED as #4211 rather than fixed across the surface boundary. CI converged 20/20 on the exact SHA. Flipping ready + auto-merge.

---

Generated by Claude Code