Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Intermittent duplicate message delivery in 2026.4.24 across all channels [1 pull requests, 1 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#72176•Fetched 2026-04-27 05:33:50
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
2
Author
bmdfbmdf
Participants
bmdfbmdf
Timeline (top)
labeled ×2cross-referenced ×1referenced ×1

After upgrading from 2026.4.23 to 2026.4.24, identical user messages are occasionally delivered twice to the session with the same timestamp but different seq numbers, causing the assistant to reply to both and producing duplicate visible messages in all channels (webchat and WeChat).

Root Cause

After upgrading from 2026.4.23 to 2026.4.24, identical user messages are occasionally delivered twice to the session with the same timestamp but different seq numbers, causing the assistant to reply to both and producing duplicate visible messages in all channels (webchat and WeChat).

Fix Action

Fix / Workaround

No workaround available — occurs at the session delivery layer.

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)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading from 2026.4.23 to 2026.4.24, identical user messages are occasionally delivered twice to the session with the same timestamp but different seq numbers, causing the assistant to reply to both and producing duplicate visible messages in all channels (webchat and WeChat).

Steps to reproduce

  1. Run OpenClaw 2026.4.24 with webchat or WeChat channel configured
  2. Send a user message from the webchat UI or WeChat
  3. Observe session history via sessions_history API
  4. Same user message appears twice in transcript with identical timestamp but sequential seq numbers (e.g., seq 2703 and seq 2705)
  5. Assistant reply is also duplicated (seq 2704 and seq 2706) with same responseId

Expected behavior

In 2026.4.23, each user message was delivered exactly once. The same message should not appear twice in the session transcript.

Actual behavior

Same user message is delivered twice with identical timestamp but different __openclaw.id and sequential seq numbers. The assistant replies to both, producing duplicate visible messages. This happens intermittently, not on every message. Confirmed via sessions_history API showing duplicate entries for both user messages and assistant replies.

OpenClaw version

2026.4.24 (cbcfdf6)

Operating system

Linux 6.6.87.2-microsoft-standard-WSL2 (x64) / Windows 11 host

Install method

npm global

Model

bailian/qwen3.6-plus (also observed with nvidia-nim/z-ai/glm4.7)

Provider / routing chain

openclaw-weixin -> gateway -> bailian (dashscope) / webchat -> gateway -> bailian

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Affected: All channels (webchat, WeChat) Severity: Medium (annoying UX, duplicate visible messages, no data loss) Frequency: Intermittent — not every message, but recurring across multiple sessions Consequence: User sees duplicate messages in chat history, making conversations hard to follow

Additional information

Last known good version: 2026.4.23 First known bad version: 2026.4.24

Session history evidence from sessions_history API:

  • User message seq 2703 at timestamp 1777207291784
  • User message seq 2705 at same timestamp 1777207291784 (duplicate)
  • Assistant reply seq 2704 at timestamp 1777207292059
  • Assistant reply seq 2706 at same timestamp 1777207292059 (duplicate)

This pattern repeats multiple times (seq 2707-2710).

Possible related changes in 2026.4.24:

  • Block streaming dedupe fix (Fixes #70921)
  • Gateway/sessions webchat mutation guard changes (Fixes #70716)
  • Gateway/WebChat image attachment preservation (Fixes #68513)

No workaround available — occurs at the session delivery layer.

extent analysis

TL;DR

The issue can likely be resolved by reverting or adjusting the changes made in the "Block streaming dedupe fix" (Fixes #70921) in version 2026.4.24, as it may be causing duplicate messages.

Guidance

  • Review the changes made in the "Block streaming dedupe fix" (Fixes #70921) to understand how it might be affecting message deduplication.
  • Investigate if the "Gateway/sessions webchat mutation guard changes" (Fixes #70716) could be contributing to the issue, possibly by allowing duplicate messages to pass through.
  • Check the session history API for patterns or clues on what might be triggering the duplicate messages, focusing on the sequence numbers and timestamps.
  • Consider temporarily downgrading to version 2026.4.23 to confirm if the issue is indeed introduced by the changes in 2026.4.24.

Example

No specific code example can be provided without more details on the implementation of the fixes mentioned, but reviewing the changes in the mentioned fixes (especially #70921) could provide insight.

Notes

The issue seems to be related to changes in how messages are handled or deduplicated in version 2026.4.24. Without access to the specific code changes or more detailed logs, it's challenging to provide a precise fix. The problem's intermittent nature and the fact that it affects all channels suggest a deeper issue with message processing.

Recommendation

Apply a workaround by downgrading to version 2026.4.23 until the root cause can be fully understood and addressed, as this version is known to work correctly. This is recommended because downgrading to a known good version can immediately mitigate the issue, allowing for further investigation and testing of the changes introduced in 2026.4.24.

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

In 2026.4.23, each user message was delivered exactly once. The same message should not appear twice in the session transcript.

#api#ssr#installation#tensor shape#autograd error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Intermittent duplicate message delivery in 2026.4.24 across all channels [1 pull requests, 1 participants]