Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On the Signal channel, a DM sent shortly after a previous turn's reply completes can be silently dropped: it hits reply session initialization conflicted and the debounce flush handler only logs the error and drops the message, with no retry and no user-visible feedback.

Steps to reproduce

1. Configure channels.signal (container mode, apiMode: "container", backed by bbernhard/signal-cli-rest-api).
2. Send a Signal DM to the bot; wait for the agent's reply to be delivered (confirmed via [signal] delivered reply to <redacted-number> in the gateway log).
3. Send a second DM in the same conversation shortly afterward (roughly 10-30s later, observed at both 23:58 and 00:04 in the attached log).
4. Observe: no reply arrives for the second message, and the gateway log shows reply session initialization conflicted for agent:main:signal:direct:<redacted-number> followed by [signal] debounce flush failed: Error: reply session initialization conflicted ..., with no retry attempt logged afterward.

Expected behavior

The follow-up message should either succeed (matching how extensions/slack/src/monitor/message-handler.ts now retries with backoff on this same error per #99647, and Telegram's equivalent handling) or at minimum surface a visible failure/retry to the user rather than silently dropping the message.

Actual behavior

The message is silently dropped. extensions/signal/src/monitor/event-handler.ts's debounce onFlush/onError path just logs signal debounce flush failed: Error: reply session initialization conflicted for <sessionKey> and does not retry, unlike the Slack/Telegram handlers which already special-case this exact error message for bounded retry-with-backoff.

OpenClaw version

2026.6.11

Operating system

Linux (Docker container on Synology DSM host)

Install method

npm global (inside a manually-run Docker container, not the bundled Mac/official Docker image)

Model

anthropic/claude-sonnet-4-6 (via claude-cli backend)

Provider / routing chain

openclaw -> claude-cli (Claude Code subscription, no API key)

Additional provider/model setup details

NOT_ENOUGH_INFO

Logs

23:56:42 [signal] delivered reply to <redacted-number>
23:56:59 [diagnostic] message dispatch completed: channel=signal sessionId=unknown sessionKey=agent:main:signal:direct:<redacted-number> source=replyResolver outcome=error duration=22ms error="Error: reply session initialization conflicted for agent:main:signal:direct:<redacted-number>"
23:56:59 [diagnostic] message processed: channel=signal chatId=<redacted-number> messageId=1783346219438 sessionId=57958c70-8a22-44da-b794-004ef9c4940f sessionKey=agent:main:signal:direct:<redacted-number> outcome=error duration=38ms error="Error: reply session initialization conflicted for agent:main:signal:direct:<redacted-number>"
23:56:59 [signal] debounce flush failed: Error: reply session initialization conflicted for agent:main:signal:direct:<redacted-number>

00:04:07 [signal] delivered reply to <redacted-number>
00:04:35 [diagnostic] message dispatch completed: channel=signal sessionId=unknown sessionKey=agent:main:signal:direct:<redacted-number> source=replyResolver outcome=error duration=21ms error="Error: reply session initialization conflicted for agent:main:signal:direct:<redacted-number>"
00:04:35 [diagnostic] message processed: channel=signal chatId=<redacted-number> messageId=1783346674292 sessionId=57958c70-8a22-44da-b794-004ef9c4940f sessionKey=agent:main:signal:direct:<redacted-number> outcome=error duration=35ms error="Error: reply session initialization conflicted for agent:main:signal:direct:<redacted-number>"
00:04:35 [signal] debounce flush failed: Error: reply session initialization conflicted for agent:main:signal:direct:<redacted-number>

Screenshots, recordings, and evidence

NOT_ENOUGH_INFO

Impact and severity

• Affected: any Signal DM user who sends a follow-up message within roughly 10-30 seconds of the previous turn's reply.
• Severity: Medium-high (silent message loss with zero visible feedback to the end user — reads as the bot being "stuck"/unresponsive).
• Frequency: observed 4 times in one session (23:56, 23:58 x2, 00:04).
• Consequence: follow-up questions are silently dropped; the user has no reply and no error indication, only a false impression the bot has hung.

Additional information

src/auto-reply/reply/session.ts:937 throws this error inside initSessionStateAttemptLocked when commitReplySessionInitialization (src/config/sessions/session-accessor.ts:1829) detects a stale snapshot after one retry. This is an intentional optimistic-concurrency guard (narrowed to identity-only fields per d2da8c79d9, "fix(auto-reply): serialize reply session initialization"), not incidental noise. Slack received bounded retry-with-backoff for this exact error in extensions/slack/src/monitor/message-handler.ts (#99647, "Fix Slack retry for session init conflicts"), and Telegram has equivalent handling (13ecca5408, 8dbcf6db16). Signal's debounce handler (extensions/signal/src/monitor/event-handler.ts:635-680, onFlush/onError at lines 652/677-679) has not received the equivalent treatment — it only logs and drops on this error.

A closed issue (#98234, "Signal direct inbound can be dropped on reply session initialization conflict in 2026.6.11 release") already reports this exact symptom, but the Signal-specific retry porting does not appear to have landed — the behavior is still fully reproducible on 2026.6.11 with the steps above.