PR #72004: fix(control-ui): stop duplicate-render race on assistant final messages (#71992)

• Repository: openclaw/openclaw
• Author: hclsys
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/72004

Description (problem / solution / changelog)

Summary

Fixes #71992.

Every assistant reply in the Control UI webchat appears exactly twice on 2026.4.21+. Server transcripts contain one assistant entry per turn — this is a client-side rendering race.

In `ui/src/ui/controllers/chat.ts#handleChatEvent`, both the `final` and `aborted` branches mutate `state.chatMessages` BEFORE clearing `state.chatStream`. Lit batches reactive updates: between the chatMessages mutation and the next render, chatStream still holds the streaming text AND chatMessages contains the committed assistant message, so Lit renders both.

Fix: capture the streamed fallback text into a local, clear chatStream / chatRunId / chatStreamStartedAt FIRST, then mutate chatMessages. The render pass observing the chatMessages change sees chatStream already null, so only the committed message renders.

The reporter cited closed PR #34164 which had this exact swap; that PR was closed for unrelated reasons (mixed-in iOS files), so the fix never landed.

New test

``clears chatStream before appending final message to prevent duplicate-render race`` uses a property accessor on chatMessages that records chatStream's value at the exact moment chatMessages mutates. Asserts chatStream is null at that moment.

Pre-implement audit (skill v6 rules)

Test plan

• `pnpm exec vitest run ui/src/ui/controllers/chat.test.ts` — 76/76 pass (74 existing + 2 new)
• Existing `appends final payload message from own run before clearing stream state` test still passes — final-state contract unchanged
• `pnpm exec oxfmt --check` — clean
• `pnpm exec oxlint` — 0 warnings/errors
• CI green
• Manual repro: open Control UI webchat, send 3+ messages, confirm no duplicates

Related

• #5964 (original report, closed as not planned)
• #39469 (regression, closed)
• #34164 (prior fix attempt, closed for unrelated mixed-in iOS files)

Changed files

• CHANGELOG.md (modified, +1/-0)
• ui/src/ui/controllers/chat.test.ts (modified, +46/-0)
• ui/src/ui/controllers/chat.ts (modified, +25/-19)

PR #72290: fix(chat): prevent duplicate user message delivery in 2026.4.24 regression

• Repository: openclaw/openclaw
• Author: chinar-amrutkar
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/72290

Description (problem / solution / changelog)

Problem

After upgrading to 2026.4.24, identical user messages are occasionally delivered twice to the session (same timestamp, different seq numbers), causing duplicate assistant replies. Affects webchat, WeChat, and potentially all channels.

Root Cause

1. Primary: Some channel retry paths generate new idempotencyKey per attempt, bypassing the primary dedupe (which uses MessageSid = clientRunId).
2. Secondary: emitUserTranscriptUpdate user messages lacked idempotencyKey, so even if inbound dedupe worked, the transcript layer couldn't catch duplicates.

Fix

1. Content-based dedupe fallback (inbound-dedupe.ts): When MessageSid is unavailable, fall back to SHA-256 hash of Body|Timestamp|peerId to catch duplicate messages regardless of ID stability.

2. Transcript idempotency (chat.ts): Add idempotencyKey: clientRunId to user message entries in emitUserTranscriptUpdate, enabling secondary dedupe at the transcript layer via transcriptHasIdempotencyKey.

Issue

Fixes #72176

Changed files

• src/auto-reply/reply/inbound-dedupe.ts (modified, +16/-2)
• src/gateway/server-methods/chat.ts (modified, +3/-0)
• src/gateway/server-methods/chat.ts.backup (added, +2838/-0)