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.
• Log unexpected scheduled queue-drain failures so background queue dispatch issues are visible.
• 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.

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
• ./build.ps1 — passed
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore — 2701 passed / 31 skipped
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore — 1597 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 current-head 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.

Current-head MCP proof

winnode --list-tools advertised both queue tools from current PR head:

"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 '{"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 }
  ]
}

Current-head 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.

Not verified / blocked

• Dropdown disable behavior is covered by source contract tests; no new manual screenshot was added for this UI-only control-state change.

[clawsweeper]

Codex review: needs changes before merge. Reviewed July 7, 2026, 7:12 PM ET / 23:12 UTC.

Summary
The PR updates native tray chat queue identity/idempotency handling, queued-message cancellation, MCP queue list/cancel tools, WinUI queue controls, docs, localization, and regression tests.

Reproducibility: yes. from source inspection: feed the PR a queued chat.send acknowledgement with status = "timeout" and a run id, and it reaches the non-empty acceptedRunId promotion path because timeout is not terminal failure. I did not run runtime tests in this read-only review.

Review metrics: 2 noteworthy metrics.

• Changed surface: 22 files, +1,822/-165. The PR spans shared gateway chat send, tray queue state, WinUI composer controls, MCP command descriptions, docs, localization, and tests.
• MCP tools added: 2 added. New local MCP commands must stay registered, documented, tested, and proven through real discovery/invocation under repository policy.

Root-cause cluster
Relationship: canonical
Canonical: #935
Summary: This PR is the active follow-up for queued chat parity after the merged initial queued-message UI work; the predecessor overlaps but does not contain the current idempotency, deferred-admission, cancel, and MCP queue work.

Members:

• partial_overlap: Add queued chat message UI #920 - The merged predecessor added the initial queued chat message UI and local queue behavior, while this PR continues that area with parity fixes and queue control surfaces.

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

Merge readiness
Overall: 🧂 unranked krab
Proof: 🦞 diamond lobster
Patch quality: 🧂 unranked krab
Result: blocked by patch quality or review findings.

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

Rank-up moves:

• Classify chat.send timeout as terminal failure before queued-send promotion.
• [P2] Add focused regression tests for queued and direct timeout acknowledgements.

Risk before merge

• [P2] Merging as-is could show a gateway-timed-out queued chat send as delivered because timeout is not classified as a terminal failure before the new queued-send promotion path.

Maintainer options:

1. Fix timeout classification before merge (recommended)
   Treat chat.send timeout as terminal failure and cover queued/direct timeout acknowledgements so the tray does not promote a timed-out queued send.
2. Pause for protocol review
   If maintainers want a different timeout UX, pause the PR until the gateway acknowledgement contract and tray failure behavior are explicitly chosen.

Copy recommended automerge instruction

@clawsweeper automerge

Special instructions:
Treat chat.send status "timeout" as a terminal failure before queued-send promotion, add focused regression coverage for queued and direct timeout acknowledgements, and preserve the existing in_flight retry/idempotency behavior.

Next step before merge

• [P2] A narrow automated repair can address the blocking timeout status defect without changing the PR’s product direction.

Security
Cleared: No concrete security or supply-chain issue was found; the queued-text READ-ALL exposure is documented and remains within the existing local MCP chat automation surface.

Review findings

• [P1] Treat timeout acks as failed sends — src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:517-525

Review details

Best possible solution:

Classify gateway timeout as a terminal chat.send failure before queued-send promotion, add regression coverage for timeout acknowledgements, then land the queue identity, cancel, and MCP queue-control repair with the existing proof.

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

Yes, from source inspection: feed the PR a queued chat.send acknowledgement with status = "timeout" and a run id, and it reaches the non-empty acceptedRunId promotion path because timeout is not terminal failure. I did not run runtime tests in this read-only review.

Is this the best way to solve the issue?

No: the provider-level queue identity/idempotency direction is the right boundary, but the patch needs terminal timeout handling before it is the narrow maintainable fix.

Full review comments:

• [P1] Treat timeout acks as failed sends — src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:517-525
  The linked gateway contract includes timeout, and the gateway clients classify it as a terminal chat.send failure, but this branch still relies on ChatSendResult.IsTerminalFailure, which does not include timeout. With the new generic acceptedRunId promotion path, a queued send that times out with a run id is promoted into the transcript and removed from the queue instead of surfacing a failed queued card. Late discovery: this was present in the previously reviewed head.
  Confidence: 0.92
  Late finding: first raised on code an earlier review cycle already covered.

Overall correctness: patch is incorrect
Overall confidence: 0.92

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 87634727b65b.

Label changes

Label changes:

• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🦞 diamond lobster and patch quality is 🧂 unranked krab.
• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (terminal): The PR body includes current-head winnode list/cancel output, UIA transcript evidence, and a screenshot showing queued cards with cancel controls; that is sufficient real behavior proof for the changed queue/MCP surface.
• remove rating: 🐚 platinum hermit: Current PR rating is rating: 🧂 unranked krab, so this older rating label is no longer current.
• remove status: 👀 ready for maintainer look: Current PR status label is status: ⏳ waiting on author.

Label justifications:

• P2: This is a normal-priority native chat queue/message-delivery repair with bounded blast radius but real user-visible delivery impact.
• merge-risk: 🚨 message-delivery: The PR changes queue admission, idempotency, cancellation, and assistant retransmit handling, so a regression can drop, duplicate, or mis-associate chat messages.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🦞 diamond lobster and patch quality is 🧂 unranked krab.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (terminal): The PR body includes current-head winnode list/cancel output, UIA transcript evidence, and a screenshot showing queued cards with cancel controls; that is sufficient real behavior proof for the changed queue/MCP surface.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes current-head winnode list/cancel output, UIA transcript evidence, and a screenshot showing queued cards with cancel controls; that is sufficient real behavior proof for the changed queue/MCP surface.

Evidence reviewed

Acceptance criteria:

• [P1] ./build.ps1.
• [P1] dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore.
• [P1] dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore.
• [P1] dotnet test ./tests/OpenClaw.WinNode.Cli.Tests/OpenClaw.WinNode.Cli.Tests.csproj --no-restore.

What I checked:

• Repository policy applied: AGENTS.md was read fully and applies because this PR touches tray chat UX, local MCP tools, Windows node command documentation, and PR proof expectations. (AGENTS.md:43, 87634727b65b)
• Current main gap: Current main has no app.chat.queue tools, no queued-message cancel provider surface, and the gateway client always generates a fresh idempotencyKey instead of accepting the queued send-run id. (src/OpenClaw.Shared/OpenClawGatewayClient.cs:337, 87634727b65b)
• PR queue identity implementation: PR head tracks a stable SendRunId for each queued request and forwards it as chat.send idempotencyKey. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:447, 4c9d270e6b23)
• Gateway timeout contract: The gateway chat-send contract includes timeout and error as possible acknowledgement statuses, and other gateway clients classify timeout as a terminal failure. (f2c6a0eda6f1)
• PR head omits timeout from terminal failure classification: ChatSendResult.IsFailureStatus in PR head recognizes error-like statuses but not timeout, so sendResult.IsTerminalFailure is false for a timeout ack without an error string. (src/OpenClaw.Shared/Models.cs:2007, 4c9d270e6b23)
• Real behavior proof inspected: The PR body includes current-head winnode list/cancel output, UIA transcript output, and a screenshot showing queued cards with cancel controls; the linked screenshot was downloaded and inspected from the proof scratch directory. (4c9d270e6b23)

Likely related people:

• calebeden: Merged current-main history for the queued chat UI and chat timeline identity paths is in the same provider, composer, root, and regression-test area this PR changes. (role: introduced queued chat behavior and recent area contributor; confidence: high; commits: c9b5476a873f, f89a88a6baf4; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawComposer.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawChatRoot.cs)
• shanselman: Current-main history introduced the app.chat MCP automation commands and shared gateway/client baseline that this PR extends. (role: adjacent shared gateway and MCP chat contributor; confidence: medium; commits: 14022dc71222, 4166e0fd63f8; files: src/OpenClaw.Shared/OpenClawGatewayClient.cs, src/OpenClaw.Shared/Mcp/McpToolBridge.cs, src/OpenClaw.WinNode.Cli/skill.md)
• bkudiess: Recent current-main work touched AppCapability, McpToolBridge, and app capability handlers near the local MCP state surfaces this PR extends. (role: adjacent app capability contributor; confidence: medium; commits: 74604aebafef; 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 (2 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

[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.