Sign up
View stargazersSign up

Can't save an edited queued message during compact-then-send: Update button stuck loading#26609

opened6d agobyAadrianorocha-dev

What happened

When a thread has been idle long enough, the composer shows the Compact chip and the next send runs "compact, then send". My message is queued behind the /compact turn and is sent right after compaction finishes. If I click Edit on the queued message during compaction, the composer switches to "Update queued message", but the send button shows a spinner and stays disabled. I can't save the edit. Once compaction finishes, the queued message is sent with its original text and the edit is lost.

Diagnosis

From reading the source at v0.1.4-nightly.20261028.3824. I did not trace it at runtime.

  1. With compactBeforeSend, useComposerSend.ts calls beginLocalDispatch(), sends a /compact turn (idleCompaction: "onReturn"), then sends the user's message, which queues behind it.
  2. useLocalDispatchState reports isSendBusy: true until hasServerAcknowledgedLocalDispatch() (ChatView.logic.ts) returns true. During the compaction run that check does not seem to pass, so the local dispatch stays pending until the queued run starts, which is after compaction.
  3. ChatView.tsx (~L3410) passes isSendBusy={(isSendBusy && !sendQueuesBehindSetup) || … || queuedRunEdit.isSaving || isResuming} to the composer. Nothing there excludes queued-edit mode.
  4. ComposerPrimaryActions.tsx uses that flag for the "Update queued message" button. isSendBusy renders a <Spinner> and sets disabled, so the edit can't be saved while the original compact-then-send dispatch is pending.

Net effect: the queued-edit save button inherits the busy state of the send that queued the message. A queued edit is a separate action and probably shouldn't be blocked by a pending dispatch, only by queuedRunEdit.isSaving.

main (as of 2026-10-28) still wires isSendBusy the same way.

Steps to reproduce

  1. In a Claude thread, let the thread sit idle until the composer shows the Compact chip (compact before send).
  2. Type a message and send it. A /compact turn starts and the message is queued behind it.
  3. While compaction is running, click Edit on the queued message.
  4. Change the text.

Expected: "Update queued message" is enabled and saves the edit. Actual: the button shows a loading spinner and stays disabled. After compaction finishes, the original text is sent.

Version

0.1.4-nightly.20261028.3824 (remote server; client connected from desktop/web)

Environment

Server: Fedora Linux x64 (kernel 7.1.10, fc44), Node v26.8.2, Claude provider. Triage CLI: 0.1.1-nightly.20261016.3203.

Evidence

shell
1# No runtime evidence captured: server traces do not record the relevant
2# orchestration command RPCs. Diagnosis is from source at the release tag.
3apps/web/src/components/ChatView.tsx isSendBusy={(isSendBusy && !sendQueuesBehindSetup) || ... || queuedRunEdit.isSaving || isResuming}
4apps/web/src/components/chat/ComposerPrimaryActions.tsx disabled={isSendBusy || ...}; {isSendBusy ? <Spinner/> : isEditingQueuedMessage ? <CheckIcon/> : ...}
5apps/web/src/components/chat/useComposerSend.ts beginLocalDispatch(...); if (compactBeforeSend) startThreadTurn({ text: "/compact", idleCompaction: "onReturn" })

#15611: the queued message sends its original text while being edited. Related, since both end with the original text sent, but different. Here the edit can't be saved at all because the save button is stuck in the busy state during compact-then-send. #24137 (follow-ups queue during automatic compaction) covers neighboring behavior.

Fix applied or workaround

None applied. Workaround: switch the Compact chip to Keep before sending, or wait for compaction to finish before composing the follow-up.

Filed by

Claude Code (claude-opus-5-5) via t3 triage

Llg-epitech3d ago
Synced from GitHub

Confirming this on 0.1.6-nightly.20261030.3917 (desktop client on macOS arm64, connected to a remote Linux x64 server, Claude provider). It is still present on main, where ChatView.tsx ~L3604 passes isSendBusy through in queued-edit mode.

Runtime evidence (server trace + projections, UTC):

  • 01:21:02.705 message.dispatch /compact with idleCompaction: "onReturn" → run 16 (running)
  • 01:21:02.853 message.dispatch with the user's message → run 17, queued
  • 01:21:02 → 01:22:11 no queued-run.edit command reached the server. Other commands on the same per-thread serial key (thread.visit every ~10s) dispatched normally, so the client command queue was healthy. The save was never attempted: the button was disabled.
  • 01:22:11.390 run 16 completed; 01:22:11.645 run 17 started with the original text

User-visible behaviour matched the report: Edit on the queued message → change text → send button spins and nothing happens → after compaction, the original text is sent and the edit is not applied.

Claude Code (claude-opus-5-5) via t3 triage