openclaw - 💡(How to fix) Fix [Bug]: WhatsApp web-auto-reply dispatches stale/cached reply to subsequent inbound message (5ms response, no LLM call) [1 comments, 2 participants]

Summary

When two WhatsApp messages arrive within ~90 seconds to the same session, the second message receives an identical copy of the first message's reply. The second reply completes in 5ms (vs 597ms for the first), proving no LLM call was made.

Steps to reproduce

1. Send a WhatsApp message to the bot (message A)
2. Wait for the reply (~30 seconds)
3. Send a different WhatsApp message (message B) within ~90 seconds
4. Message B receives the exact same reply as message A

Expected behavior

Each inbound message should trigger an independent agent run and receive a unique reply.

Actual behavior

The second message receives a stale/cached reply from the first message's agent run. The durationMs field in logs confirms no LLM processing occurred:

• First reply: durationMs: 597 (real LLM call)
• Second reply: durationMs: 5 (no LLM call — stale dispatch)

Log evidence

# Message 1 inbound (15:28:48 ART)
correlationId: 3AE2A42602913193BB10
body: "Eh? Si muchas veces hablamos por audios..."
→ Reply at 15:29:14 (597ms): "Tenés razón, perdón. Me enfoco..."

# Message 2 inbound (15:30:31 ART) — DIFFERENT content
correlationId: 3A3C6E23063F4C7DEB06  
body: "Es 3x3 metros la sala maso. Ok ella quiere un depósito..."
→ Reply at 15:31:35 (5ms): "Tenés razón, perdón. Me enfoco..." ← IDENTICAL to reply 1

Both replies originated from the same web-auto-reply runId (4115b651-fd46-4cb5-b36b-36fd2a77d581), same WhatsApp connection.

Hypothesis

The dispatchReplyWithBufferedBlockDispatcher in dispatch-BZkerDGi.js appears to re-dispatch a buffered/pending payload when a new inbound arrives before the dispatcher state is fully cleared. The 5ms response time rules out any LLM involvement — the reply was served from an in-memory buffer or dispatcher queue.

This is distinct from #19373 (Slack duplicate, fixed via inbound dedup). Here, inbound dedup works correctly (different MessageSid values). The issue is in the outbound reply dispatch path.

Environment

• OpenClaw version: 2026.4.2 (d74a122)
• Channel: WhatsApp (personal/web mode)
• OS: macOS Darwin 25.3.0 (arm64)
• Agent model: anthropic/claude-opus-4-6
• Install: npm global

Impact

High — Users receive incorrect/irrelevant replies to their messages. In production this would be a trust-breaking experience. The bug is intermittent and depends on message timing relative to the dispatcher buffer lifecycle.