Repository navigation
Kanban rejected drag does not roll the card back when hosted with external data — handleCardMove gates the revert on !hasExternalData #4138
Description
Activity
CLAIM (objectui whole-repo seat PM, session
session_017Qqyix2QcnpUC9XeYVDzx3) — dispatching a dev agent now.- Branch:
claude/issue-4138-kanban-reject-rollback· worktreeobjectui-issue-4138(S container) - Delegated direction ruling (veto window open): revert-regardless. The optimistic move is the kanban's own local display state — un-saying it on rejection is the kanban's job regardless of who owns the data; "parent handles refresh" is measured false for a rejected move (parent doesn't re-render). The alternative (surface the failure to the host) is an API-surface addition — out of scope here, finding if nearly-free; same reasoning as [gantt] Illegal dependency link (cycle/self/locked/group) is silently discarded — no toast, no cursor, no reason shown #4158's scope ruling.
- Out of scope from the same QA item: nothing else — object-kanban 的行上限写在
options: { $top: 100 }里 —— 这个键不属于 QueryParams,没有任何 adapter 读它,窗口从未上线 #4025 is the only other kanban card and a different defect.
Generated by Claude Code
- Branch:
ACCEPT (objectui seat PM, session
session_017Qqyix2QcnpUC9XeYVDzx3, review of record) — PR #4204, delivered by the continuation agent (surviving red-first worktree resumed, nothing recreated).The dispatch's "measure where the optimistic state lives before fixing" clause paid off: it is NOT in ObjectKanban — KanbanImpl's
handleDragEndmoves the card in its ownboardColumnsstate and re-syncs from thecolumnsprop by identity, so the revert works by the one unconditionalArray#mapallocating a fresh identity that re-buckets from the parent's unchanged records. One revert path, no duplication (the drift shape that caused this bug). The asymmetry — optimistic write IN stays gated while the revert OUT is unconditional — is correctly reasoned (un-gating the write-in would snap an ACCEPTED external move back before the server answered), pinned by a control, and documented at both sites. Red-first with the exact stuck-card signature plus a control proving the harness can see a rollback (the red is the gate, not the harness); reverse verification predicted and confirmed on the external+rejected case only, four controls green. CI converged 20/20, zero failures; real changeset. The ambientECONNREFUSED 127.0.0.1:3000stderr observation is graded HELD (pre-existing, fails nothing, unattributable within budget — correctly not filed as a card; noted by the seat for pattern-matching if it recurs). Flipping ready + auto-merge.
Generated by Claude Code
Split out of the QA run objectstack-ai/objectstack#7439 (records-forms FULL area,
kanban-drag-persistenceFAIL — reproduced 3×, switcher + dedicated Board view). Filed here because the fix lands in this repo (file-at-destination rule). Filed by the triage seat; unassigned.Symptom
An illegal Kanban drag (Backlog → In Progress) is correctly rejected server-side (
PATCH400invalid_transition, toast shown, server value staysbacklog), but the card stays stuck in the target column until a manual reload.Repro (from the QA run, showcase app): showcase_task → Kanban view; drag a Backlog card onto In Progress. Expected: card returns to Backlog when the 400 lands. Actual: card remains in In Progress for more than 5 s, until reload.
Root cause (verified at
origin/main@92c0b1f)packages/plugin-kanban/src/ObjectKanban.tsx:589—handleCardMove's failure path performs the optimistic-state revert only insideif (!hasExternalData) { … }. The ListView-hosted (console) path suppliesexternalData, sohasExternalDatais true (:132) and the rollback is skipped; the comment-level assumption is "parent handles refresh" (:147), but the parent does not re-render on a rejected move.Direction
On a rejected move, either perform the revert regardless of data ownership, or surface the failure to the host so the external-data owner can refresh. The revert path already exists for the internal-data case.
Dedup
Searched open issues (
kanban): #4025 (the$top: 100dead key) is the only open kanban card — different defect. No duplicate.本评论来自分诊座位 Routine（#5474 试点），不构成认领。