Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Control UI renders user messages twice: optimistic "You" message and gateway echo "openclaw-control-ui" are not deduplicated [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#72227•Fetched 2026-04-27 05:33:00
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
alamanxpalamanxp
Participants
alamanxpalamanxpclawsweeper[bot]clawsweeper[bot]
Timeline (top)
cross-referenced ×2labeled ×2closed ×1commented ×1

Control UI /chat renders the same user message twice, once as You and once as openclaw-control-ui.

Root Cause

Control UI /chat renders the same user message twice, once as You and once as openclaw-control-ui.

Fix Action

Fixed

PR fix notes

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

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)

Code Example

<span class="chat-sender-name">openclaw-control-ui</span>

### OpenClaw version

v2026.4.24

### Operating system

Ubuntu 24.04

### Install method

_No response_

### Model

This problem exists in any model.

### Provider / routing chain

Browser (Edge/Chrome on Windows) → Control UI `/chat` at `http://127.0.0.1:19889/chat` → WebSocket connection to local OpenClaw Gateway `ws://127.0.0.1:19889` → Gateway identifies the webchat client as `openclaw-control-ui webchat vcontrol-ui` → OpenClaw embedded agent → configured model

### Additional provider/model setup details

_No response_

### Logs, screenshots, and evidence
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Control UI /chat renders the same user message twice, once as You and once as openclaw-control-ui.

Steps to reproduce

  1. Start the OpenClaw gateway.

  2. Open Control UI at:

    http://127.0.0.1:19889/chat

  3. Make sure only one Control UI tab/window is open.

  4. Send a single user message, for example:

    你好

  5. Observe the chat transcript.

Actual result:

The same user message is rendered twice:

  • You: hello
  • openclaw-control-ui: hello

Expected result:

The message should be rendered once as the local user message. If the gateway echoes the message back to the Control UI, the UI should reconcile it with the existing local message instead of appending a second message.

Expected behavior

.NOT_ENOUGH_INFO

Actual behavior

After sending a single user message in Control UI /chat, the chat transcript shows the same message twice with two different sender labels:

  • You: hello
  • openclaw-control-ui: hello

The DOM also shows the duplicated message rendered with:

<span class="chat-sender-name">openclaw-control-ui</span>

### OpenClaw version

v2026.4.24

### Operating system

Ubuntu 24.04

### Install method

_No response_

### Model

This problem exists in any model.

### Provider / routing chain

Browser (Edge/Chrome on Windows) → Control UI `/chat` at `http://127.0.0.1:19889/chat` → WebSocket connection to local OpenClaw Gateway `ws://127.0.0.1:19889` → Gateway identifies the webchat client as `openclaw-control-ui webchat vcontrol-ui` → OpenClaw embedded agent → configured model

### Additional provider/model setup details

_No response_

### Logs, screenshots, and evidence

```shell

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The issue can be fixed by modifying the Control UI to reconcile echoed messages from the OpenClaw gateway, preventing duplicate rendering of user messages.

Guidance

  • Investigate the WebSocket connection handling in the Control UI to identify why echoed messages are not being reconciled with the original user message.
  • Review the message processing logic to determine if there's a condition that allows messages from openclaw-control-ui to be treated as separate entities from the local user's messages.
  • Consider implementing a check to ignore or merge messages received from the gateway that match the user's previous input, to prevent duplication.
  • Examine the gateway's configuration to see if there's an option to disable echoing user messages or if the echo behavior can be modified.

Example

No specific code example can be provided without more details on the implementation, but a hypothetical check might look like:

if (receivedMessage.sender === 'openclaw-control-ui' && receivedMessage.text === lastUserMessage) {
  // Ignore or merge the message to prevent duplication
}

Notes

The exact solution depends on the specifics of the Control UI and OpenClaw gateway implementations, which are not fully detailed in the issue. The provided guidance is based on the information given and may need adjustment based on the actual code and system behavior.

Recommendation

Apply a workaround by modifying the Control UI's message handling logic to reconcile echoed messages, as upgrading to a fixed version is not mentioned as an option in the issue. This approach directly addresses the observed behavior and can provide a quicker resolution to the problem.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

.NOT_ENOUGH_INFO

#model loading#dependency error#configuration error#environment variable#network issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING