Fix queued chat message parity

[calebeden]

Summary

• A continuation of Add queued chat message UI #920, which was a draft PR that got merged prematurely.
• Mirror web UI queue behavior by assigning each queued tray message a stable send run ID and forwarding it as chat.send.idempotencyKey.
• Reconcile queued user messages by queued/run identity instead of prompt text so duplicate prompts remain distinct.
• Treat in_flight as deferred admission with bounded backoff, visible failure on exhaustion, safe handling for active-run/direct-send races, and preserved run/idempotency correlation through lifecycle promotion or terminal cleanup.
• Drop ambiguous identity-less assistant retransmits around queued-user boundaries instead of replaying stale output onto the next prompt.
• Add per-entry cancel/remove controls for native queued chat cards, keyed by local queue identity, so queued or failed entries can be removed without affecting duplicate-text siblings.
• Add MCP queue list/cancel commands so agents can inspect queued outgoing messages and cancel queued entries by local queue ID.
• Disable the model and reasoning dropdowns while an assistant turn is active or queued messages remain; the session switcher stays enabled.
• Harden follow-up queue cleanup by clearing stale scheduled-drain guards, clearing local-run markers only once a thread is idle after queued cancel, logging queued send IDs on failures, and documenting ephemeral queue IDs.

Validation

• Focused queue retry tests: 5 passed
• Focused queue cancel tests: 4 passed
• Focused retry stress loop: 10/10 iterations passed on affected queue retry tests
• Focused in-flight/deferred-admission tests: 9 passed
• Focused dropdown/source contract tests: 7 passed
• Focused follow-up queue cleanup tests: 4 passed
• ./build.ps1 — passed
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore — 2716 passed / 31 skipped
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore — 1604 passed
• dotnet test ./tests/OpenClaw.WinNode.Cli.Tests/OpenClaw.WinNode.Cli.Tests.csproj --no-restore — 120 passed

Gateway status contract

• Verified against the gateway ChatSendAckStatus definition: "started" | "in_flight" | "ok" | "timeout" | "error".
• For tray queue handling, in_flight is the deferred non-terminal admission status. timeout and error are terminal failure statuses, started is accepted/admitted, and ok is completed/idempotent success.

Real behavior proof

• Manual WinUI test submitted three identical hello messages through the tray chat UI; all three drained successfully, leaving 0 queued cards and 3 visible hello user turns.
• UIA proof verified two duplicate queued cards exposed distinct cancel controls; invoking one cancel action removed only that queued item and left its duplicate sibling queued.
• Real wire-contract proof added in GatewayProtocolLiveRoundTripTests.ChatSend_UsesCallerProvidedIdempotencyKeyOnWire, proving OpenClawGatewayClient sends caller-provided idempotencyKey.
• Regression proof added in QueuedSend_InFlightAckThenLifecycleBeforeRetry_PromotesWithoutResend, covering in_flight followed by matching lifecycle.start before retry, with no resend and no duplicate user echo.
• Follow-up regression proof added for stale drain guard cleanup, remote backfill after canceling the last queued item, and deferred in_flight cancel behavior without unsafe chat.abort.

MCP proof

winnode --list-tools advertised both queue tools from this PR:

"name": "app.chat.queue.list",
"description": "READ-ALL: List native chat outgoing queue entries..."
"name": "app.chat.queue.cancel",
"description": "Cancel/remove one native chat outgoing queue entry before it is sent..."

Controlled proof run proof-155257 queued two duplicate outgoing messages, listed both over MCP, canceled only q2, and confirmed q3 remained queued:

winnode --command app.chat.queue.list --params '{}'
{
  "totalCount": 2,
  "messages": [
    { "id": "q2", "text": "MCP queue proof duplicate proof-155257", "sendState": "Queued", "canCancel": true },
    { "id": "q3", "text": "MCP queue proof duplicate proof-155257", "sendState": "Queued", "canCancel": true }
  ]
}

winnode --command app.chat.queue.cancel --params '{"threadId":"agent:main:main","queuedMessageId":"q2"}'
{
  "canceled": true,
  "threadId": "agent:main:main",
  "queuedMessageId": "q2",
  "remainingCount": 1,
  "error": null
}

winnode --command app.chat.queue.list --params '{}'
{
  "totalCount": 1,
  "messages": [
    { "id": "q3", "text": "MCP queue proof duplicate proof-155257", "sendState": "Queued", "canCancel": true }
  ]
}

UIA transcript

After the MCP cancel, UIA saw the remaining duplicate queued card and exactly one cancel control for that sibling:

winapp ui search 'proof-155257' -a OpenClaw.Tray.WinUI
  Group "Queued message: MCP queue proof duplicate proof-155257"
  Text "MCP queue proof duplicate proof-155257"
  ChatQueuedMessageCancel_q3 Button "Cancel queued message 1: MCP queue proof duplicate proof-155257"
Found 4 matches

winapp ui search 'Cancel queued message' -a OpenClaw.Tray.WinUI
  ChatQueuedMessageCancel_q3 Button "Cancel queued message 1: MCP queue proof duplicate proof-155257"
Found 1 matches

Screenshot of queued messages:

Review

• Rubber-duck review: no blocking/actionable correctness findings after final pass.
• Code review: no actionable findings after final pass.
• Hanselman adversarial follow-up review: no blocking or high-consensus findings; accepted test/log/readability findings were addressed.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed July 8, 2026, 4:34 PM ET / 20:34 UTC.

Summary
The branch hardens native tray queued chat identity, retry, failure, and cancel behavior, adds local MCP queue list/cancel tools, updates docs/localization, and expands queue regression coverage.

Reproducibility: yes. source-reproducible: the PR includes focused regressions and live WinUI/UIA/MCP proof for duplicate queued messages, in_flight retry, timeout handling, and queue cancel behavior. I did not run a live current-main failing reproduction in this read-only review.

Review metrics: 3 noteworthy metrics.

• Merge surface: 24 files changed, 2222 added, 176 deleted. The PR spans chat state, WinUI controls, MCP wiring, docs, localization, and tests.
• New local MCP tools: 2 commands added. AGENTS.md requires new Windows node calls to be registered, documented, tested, and proven through MCP.
• Human review state: 1 active CHANGES_REQUESTED review. Maintainers need that review rechecked before treating the queue state-machine patch as merge-ready.

Root-cause cluster
Relationship: canonical
Canonical: #935
Summary: This PR is the active hardening and follow-up path for queued chat message behavior introduced by the merged queued UI PR.

Members:

• partial_overlap: Add queued chat message UI #920 - The merged queued chat UI PR introduced the queue behavior this PR continues and hardens, but it is closed and merged rather than the active landing target.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Have the active changes-requested reviewer re-check the latest head.

Risk before merge

• [P1] This PR changes queued-send admission, retry, cancellation, and local echo suppression; a regression could drop, duplicate, or mis-associate same-text chat messages.
• [P1] A CHANGES_REQUESTED review is still active, so maintainers should have that reviewer re-check the latest local-echo/idempotency changes before merge.

Maintainer options:

1. Re-review the queue state machine (recommended)
   Have the active reviewer verify the latest local-echo, timeout, in_flight, and cancel tests/proof before merge.
2. Ask for one more focused runtime transcript
   If maintainers remain unsure, request a current-head duplicate-prompt in_flight run transcript before merging.
3. Accept the state-machine risk
   Maintainers may merge after deciding the provided tests and proof are enough despite the message-delivery blast radius.

Next step before merge

• [P2] The branch has sufficient proof and no new actionable Codex finding, but an active changes-requested review on message-delivery-sensitive queue state must be rechecked by a human.

Maintainer decision needed

• Question: Do the latest commits satisfy shanselman's local-echo suppressor blocker for queued in_flight retries?
• Rationale: The source and regression test now appear to address the blocker, but ClawSweeper should not override an active human changes-requested review on message-delivery-sensitive queue behavior.
• Likely owner: shanselman — He authored the active changes-requested review and has adjacent ownership of the MCP chat automation surface.
• Options:
  • Re-review and clear if satisfied (recommended): Verify the current-head suppressor/idempotency regression coverage and clear or approve the review if it matches the requested fix.
  • Request one targeted follow-up: If the latest suppressor logic still misses an edge case, ask for a narrow state-machine or regression-test update before merge.

Security
Cleared: No concrete security or supply-chain regression was found; the new queue list command is a documented local READ-ALL MCP surface consistent with existing chat snapshot behavior.

Review details

Best possible solution:

Have the active reviewer re-check current head, then merge once the changes-requested review is resolved and required checks are green.

Do we have a high-confidence way to reproduce the issue?

Yes, source-reproducible: the PR includes focused regressions and live WinUI/UIA/MCP proof for duplicate queued messages, in_flight retry, timeout handling, and queue cancel behavior. I did not run a live current-main failing reproduction in this read-only review.

Is this the best way to solve the issue?

Yes, the current approach looks like the narrow maintainable fix: stable queued run IDs feed chat.send idempotency keys, local queue identity drives reconciliation/cancel, and MCP docs/tests cover the new command surface. The remaining blocker is human re-review, not a new implementation path.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 0d11a8ae6a49.

Label changes

Label justifications:

• P2: This is a normal-priority queued chat correctness improvement with meaningful but bounded blast radius.
• merge-risk: 🚨 message-delivery: The patch changes queued chat send identity, retry, cancellation, and echo suppression paths where a regression could drop or duplicate messages.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body includes current-head manual WinUI/UIA duplicate-queue proof plus live winnode list/cancel output that directly exercises the changed queue behavior.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes current-head manual WinUI/UIA duplicate-queue proof plus live winnode list/cancel output that directly exercises the changed queue behavior.

Evidence reviewed

What I checked:

• Repository policy read and applied: AGENTS.md was read fully; its UI/MCP proof and new Windows node command guidance applies because this PR changes chat UX, MCP tools, winnode docs, and command tests. (AGENTS.md:31, 0d11a8ae6a49)
• Current main lacks the new queue surface: A current-main search found no app.chat.queue commands, CancelQueuedMessageAsync, ChatQueue handlers, or stable queued SendRunId forwarding, so the central work is not already implemented on main. (0d11a8ae6a49)
• Active human review remains: Live PR metadata shows reviewDecision CHANGES_REQUESTED from shanselman on the earlier queue-state-machine blocker, with current head 8943b29 and mergeStateStatus UNSTABLE. (8943b29eae9d)
• Stable queued idempotency key forwarding: PR head creates a per-message SendRunId and passes it as chat.send idempotencyKey through the gateway bridge. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:447, 8943b29eae9d)
• Prior suppressor blocker appears addressed: PR head removes existing local echo suppressors before enqueueing a retry, clears all suppressors for the matched queued id, and adds the requested same-text remote-user regression test. (tests/OpenClaw.Tray.Tests/OpenClawChatDataProviderTests.cs:3165, 8943b29eae9d)

Likely related people:

• calebeden: He authored the merged queued chat UI work this branch hardens and adjacent chat timeline identity work on current main. (role: feature owner and recent area contributor; confidence: high; commits: c9b5476a873f, f89a88a6baf4; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawComposer.cs, tests/OpenClaw.Tray.Tests/OpenClawChatDataProviderTests.cs)
• shanselman: He authored the active changes-requested review and introduced the adjacent local MCP chat automation command surface. (role: reviewer and adjacent MCP chat owner; confidence: high; commits: 14022dc71222; files: src/OpenClaw.Shared/Capabilities/AppCapability.cs, src/OpenClaw.Shared/Mcp/McpToolBridge.cs, src/OpenClaw.Tray.WinUI/App.CapabilityHandlers.cs)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Review history (6 earlier review cycles)

• reviewed 2026-07-07T21:43:33.927Z sha 4c9d270 :: needs real behavior proof before merge. :: none
• reviewed 2026-07-07T22:58:46.005Z sha 4c9d270 :: needs maintainer review before merge. :: none
• reviewed 2026-07-07T23:12:33.846Z sha 4c9d270 :: needs changes before merge. :: [P1] Treat timeout acks as failed sends
• reviewed 2026-07-08T18:35:37.559Z sha 1cdb7e0 :: needs maintainer review before merge. :: none
• reviewed 2026-07-08T18:40:43.978Z sha 1cdb7e0 :: needs maintainer review before merge. :: none
• reviewed 2026-07-08T20:29:21.495Z sha 8943b29 :: needs maintainer review before merge. :: none

[shanselman]

Caleb, first: this is a strong cleanup PR. The hard parts here are exactly the right things to be thinking about: stable queue identity instead of prompt-text matching, idempotency keys that survive retries, bounded retry terminality, and cancel/remove actions keyed by local queue identity. That is good engineering progress, especially given this is cleaning up a prematurely-merged draft path.

I did a dual-model adversarial pass and one issue looks real enough that I want to hold merge until it is fixed. The good news: it is a focused state-machine cleanup, and the fix should be straightforward.

Blocking before merge

Deferred in_flight retries can leave stale local-echo suppressors

When a queued send gets chat.send status in_flight, the provider requeues and retries with the same stable send/idempotency key. That part is good. The gap is that each retry path can enqueue another LocalSentText suppressor for the same queued message, while the consume/remove paths only clear one matching entry.

Why it matters: after the first gateway echo is consumed, a leftover suppressor for the same queued message/text can still be present. A later legitimate same-text user message from another client could be treated as “our echo” and dropped from the timeline.

Places to look:

• OpenClawChatDataProvider.cs
  • EnqueueLocalEchoLocked
  • TryConsumeLocalEchoLocked
  • RemovePendingLocalEchoLocked
  • deferred admission path around RequeueDeferredAdmissionLocked

Suggested fix:

1. Make local echo suppressor tracking idempotent by QueuedMessageId.
2. Before enqueueing a new LocalSentText, remove/replace any existing entry for that same queued message id.
3. When removing/consuming by queued message id, clear all entries for that id, not just the first one.
4. Add a regression test: queued send gets in_flight, retries, first same-text gateway echo is consumed/reconciled, then a separate later same-text remote user message should render as a distinct user entry.

A good done signal would be a test with a name like:

QueuedSend_InFlightRetry_DoesNotSuppressLaterSameTextRemoteUserMessage

Non-blocking follow-ups

These should not block this PR unless you want to handle them while you are in the area:

• Failed queue cards currently keep model/reasoning dropdowns disabled because the composer gates on queuedMessages.Count, not just pending Queued/Sending work. A failed card is terminal, so it probably should not block changing model/reasoning before retry.
• app.chat.queue.cancel without threadId can fail after app.chat.queue.list returns all threads, because cancel defaults to the current compose/default thread. Either requiring threadId in docs or scanning all queued threads when omitted would make automation friendlier.

Also confirmed: app.chat.queue.list / app.chat.queue.cancel being local MCP-only Windows Hub app commands is okay. They are not gateway RPCs, and the docs correctly describe them as local tray automation hooks. The cross-platform gateway contract surface touched here is the existing chat.send.idempotencyKey, which is the right place to align with OpenClaw queue behavior.

Once the blocker fix + regression test is in and CI is green, I expect this to be mergeable.

[shanselman]

Reviewed follow-up changes with >90% confidence. The prior stale local-echo suppressor blocker is fixed by queued-message-id dedupe/removal and covered by QueuedSend_InFlightRetry_DoesNotSuppressLaterSameTextRemoteUserMessage. Current CI is green; MCP docs/proof now align with the required threadId contract.