openclaw - 💡(How to fix) Fix [Bug] Web UI: Duplicate messages after WebSocket reconnect (2026.4.24) [2 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#71890Fetched 2026-04-27 05:37:45
View on GitHub
Comments
2
Participants
2
Timeline
4
Reactions
0
Author
Participants
Timeline (top)
cross-referenced ×2closed ×1commented ×1

Root Cause

Root Cause (from community analysis)

From issue #39686: WebSocket reconnect triggers loadChatHistory() without deduplication — messages are appended/replaced without checking for existing entries, causing duplicates to appear in the UI.

Fix Action

Workaround

Refresh the page (F5) before sending messages after a gateway restart. Clean reconnect avoids the duplicate rendering.

RAW_BUFFERClick to expand / collapse

Bug Description

After gateway restart or WebSocket reconnect, messages in the web UI (openclaw-control-ui) are displayed twice — once labeled as 'openclaw-control-ui' and once as 'You' — with identical content and timestamps.

Steps to Reproduce

  1. Open web UI (http://127.0.0.1:18789/)
  2. Send a message via web UI
  3. Restart gateway: openclaw gateway restart
  4. Web UI reconnects automatically
  5. All messages now appear twice in the conversation history

Expected Behavior

Messages should appear exactly once after reconnect, with correct sender labels.

Actual Behavior

Each message is rendered twice:

  • First instance: labeled openclaw-control-ui
  • Second instance: labeled You

Both instances have identical timestamps, content, and metadata (token counts, model, context %).

Root Cause (from community analysis)

From issue #39686: WebSocket reconnect triggers loadChatHistory() without deduplication — messages are appended/replaced without checking for existing entries, causing duplicates to appear in the UI.

Environment

  • OpenClaw version: 2026.4.24
  • Platform: macOS (Darwin 25.4.0, arm64)
  • Connection: WebSocket (webchat)
  • Model: MiniMax-M2.7-HighSpeed
  • Channel: Feishu (no duplication in Feishu — only in web UI)

Screenshots

Duplicate messages in web UI showing both openclaw-control-ui and You labels for the same messages.

Impact

  • Visual only — actual message delivery is correct (Feishu receives single messages)
  • Does not affect functionality but significantly impacts UX readability

Workaround

Refresh the page (F5) before sending messages after a gateway restart. Clean reconnect avoids the duplicate rendering.

extent analysis

TL;DR

Implementing deduplication in the loadChatHistory() function after WebSocket reconnects is likely to fix the issue of duplicate messages in the web UI.

Guidance

  • Review the loadChatHistory() function to understand how it handles message loading after a WebSocket reconnect, focusing on why it doesn't currently remove or prevent duplicates.
  • Consider adding a check for existing messages before appending new ones to the chat history, ensuring that messages with the same content and timestamp are not added twice.
  • Test the workaround of refreshing the page before sending messages after a gateway restart to confirm it temporarily resolves the issue, which can help verify the root cause analysis.
  • Investigate if there are any existing functions or utilities within the OpenClaw framework that can be leveraged for message deduplication, to avoid reinventing the wheel.

Example

// Pseudo-example of how deduplication might be implemented
function loadChatHistory() {
  const existingMessages = getExistingMessages(); // Assume this function exists
  const newMessages = fetchNewMessages(); // Assume this function exists
  
  newMessages.forEach(message => {
    if (!existingMessages.find(existing => existing.content === message.content && existing.timestamp === message.timestamp)) {
      addMessageToHistory(message);
    }
  });
}

Notes

The provided workaround suggests that the issue is closely related to how the web UI handles reconnects and loads chat history. The fix should focus on ensuring that messages are not duplicated during this process.

Recommendation

Apply a workaround by modifying the loadChatHistory() function to include deduplication logic, as this directly addresses the identified root cause and should resolve the visual duplication issue in the web UI.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING