[Bug] Queue edit acknowledgements discard text typed while a save is pending

[GCSimba]

I reproduced a queued-message editing race on master at 687f282e8625c6b8d11ff58211a90524be2e4317 (0.2.1-rc.2). A successful response to an earlier save closes the editor even when the user has typed a newer draft in the meantime. The newer, unsaved text disappears.

A deterministic reproduction is:

1. While an agent turn is running, queue a message and open its inline editor.
2. Change its text to revision A and save. Delay the response from /api/session/updateQueue; the regression test lets the real Host process the request before holding its response.
3. While that response is pending, type revision B in the editor, which remains editable.
4. Release the response for A.

The Host has correctly saved A, but the original UI closes the editor and discards B. The expected behavior is to keep B visible until the user explicitly saves or cancels it. Repeated Enter presses while a save is pending can also dispatch concurrent edits, despite the disabled Save button.

QueueDock.saveEdit() unconditionally cleared editing state after success. The keyboard save path also lacked a synchronous guard against another in-flight queue mutation. The patch captures the submitted edit object and clears the editor only if that same revision is still current. A component-owned latch admits one queue mutation until it settles. Object identity also preserves a later revision whose text was edited away and then back to the submitted value.

The product fix is a self-contained commit: b6ecf345c3. It includes component regressions, an assembled Chromium regression, an expected UI snapshot, and bilingual documentation. Host queue behavior, public types, RPC fields, Session events, and persisted formats are unchanged.

The component regressions cover later typing, returning to the submitted text, repeated saves, failure/retry, cancellation, and queue-row retirement. Before the fix, three new regression cases failed. After the fix, the owning component file passed all 41 tests. In the browser regression, the real Host response is delayed, the newer draft remains visible, repeated Enter produces no additional pending request, and a later explicit save reaches the durable user message.

Validation performed locally:

• corepack pnpm exec vitest run packages/client/ui-conversation/tests/queue-dock.client.spec.tsx --maxWorkers=1 --no-color — 41 passed.
• corepack pnpm exec vitest run --config vitest.web.config.ts apps/web/tests/queue-actions.e2e.ts --maxWorkers=1 --no-color — 5 passed in keyless replay mode. Both modified variants also passed after a mechanical test-type correction.
• corepack pnpm run build — 9 gates passed; corepack pnpm run build:check subsequently passed both aggregate checks.
• corepack pnpm run doc-sync with DSH_GATE_CONCURRENCY=2 — 42 gates passed; CLI-help generation hit its existing subprocess timeout during the concurrent run. The unchanged corepack pnpm run verify-cli-help command then passed in isolation, with all 7 help pages current.
• corepack pnpm run lint:contracts-ready with DSH_OXLINT_THREADS=2 — passed after correcting one line-length error; one existing unused-disable warning remains in the experimental translation package.
• Normal pre-commit hooks passed for all three commits, and the pre-push typecheck passed all 5 gates.

The fork branch also contains two separate validation fixes: portable Windows link-test fixtures and decimal-data false positives in the repository-reference checker. The two link-test files passed 94 tests on both Windows and Linux; the reference-checker file passed 69 tests with one existing skip on Windows and all 70 on Linux. The QueueDock commit can be cherry-picked independently.

A retained later draft is still local and requires another explicit save; it does not persist across reloads, cancellation, or removal of its queued row. The upstream coverage configuration excludes this QueueDock source, so the focused coverage run yielded no file-coverage measurement.

On 2026-10-23, I searched public Discussions for QueueDock, queued save typing, and queue editing lost, and Issues/PRs for QueueDock. I did not find an equivalent report within those searches.

This investigation and implementation were prepared with Codex, which is recorded as co-author on the commits.

Would you consider adopting the QueueDock commit? Feedback on the draft-revision and pending-action behavior would be welcome.

[takomitkm]

I checked current master at fcc0ad4, and this still looks relevant beyond the original rc.2 report:

• QueueDock.saveEdit() still closes the editor after the awaited update succeeds, without checking whether the current edit is the submitted revision.
• InlineEditor takes a void onSave callback and remains editable; disabling the Save button therefore does not cover repeated Enter through that path.

This is a source-level check, not a fresh runtime reproduction. Your standalone QueueDock patch and delayed real-Host-response regression appear to address the right boundary already. In particular, preserving edit-session/revision identity rather than comparing text matters when someone edits away from A and then back to A while its save is pending.

I'd support adopting the focused fix with those regressions: A is saved once, a newer local edit stays visible, and another save is admitted only after the pending operation settles. This can protect the newer input without changing the Host queue protocol or persisted message format.