Summary

A specific Telegram forum topic (thread_id=905 in our case) becomes a permanent inbound black hole: Telegram pushes updates to the bot, OpenClaw acks them off the long-poll queue, but no Inbound message ... log line ever appears for that thread and the agent never sees the message. Other topics in the same chat continue to work normally. Outbound to the same thread keeps working.

This is reproducible across multiple gateway restarts and survives session-store deletion. We have not found a way to recover the affected thread without abandoning it.

Environment

• OpenClaw 2026.6.1 (commit 2e08f0f)
• macOS 26.4 (arm64), Node 26.0.0
• Telegram provider: polling mode, isolated polling ingress
• Forum group is_forum: true, bot is status: member
• Affected thread: message_thread_id=905
• Other threads in the same group (topic:17, topic:13, direct chat): unaffected

What works

• Outbound to topic 905: openclaw message send --thread-id 905 ... succeeds, message arrives in the Telegram client.
• Inbound to other topics in the same chat (e.g. topic 17): works end-to-end, agent replies normally.
• Inbound to direct chat: works.
• Bot membership / permissions: getChatMember returns status: member for the group.
• Telegram side: getUpdates?offset=-N returns [] after the user posts → confirms OpenClaw acked the update off Telegram's queue.

What is broken

For thread 905 specifically:

1. User sends a message in topic 905.
2. Telegram queues the update for the bot.
3. OpenClaw polling acks it (Telegram side queue drains to []).
4. No Inbound message telegram:group:...:topic:905 ... log line is written.
5. Agent never receives the message; user never gets a reply.

This persists through:

• 5+ openclaw gateway restart cycles
• Clearing claudeCliSessionId / cliSessionIds / cliSessionBindings for topic 905 in sessions.json
• Resetting status: "failed" → unset on the session row
• Deleting the entire topic 905 entry from sessions.json and the underlying transcript JSONL
• Sending an explicit bot mention in topic 905

Suspicious log evidence

(All chat ids / user ids / bot username redacted as -100XXXXXXXXXX, 5XXXXXXX62, REDACTED_BOT.)

1. Stale lane guard (around the time the black hole started)

2026-06-09T08:49:04 [telegram] [diag] timed out spooled update 939635924 had no active reply fence on lane telegram:-100XXXXXXXXXX:topic:905; keeping the lane guarded until the handler stops.
2026-06-09T08:49:09 [telegram] [diag] timed out spooled update 939635924 did not stop within 5s after reply abort; keeping lane telegram:-100XXXXXXXXXX:topic:905 guarded.

After this line, no further inbound for topic:905 is ever logged. The guard is supposed to be in-process state (activeSpooledUpdateHandlersByLane Map in monitor-polling.runtime-*.js), so it should clear on restart — but the black hole survives every restart.

2. Mismatched session key format

2026-06-09T00:11:24 [ws] ⇄ res ✗ sessions.resolve 8ms errorCode=INVALID_REQUEST errorMessage=No session found: telegram:-100XXXXXXXXXX:905

The key telegram:-100XXXXXXXXXX:905 is missing the topic: segment that real session keys use (agent:main:telegram:group:-100XXXXXXXXXX:topic:905). Some caller is constructing the wrong key and silently failing the resolve. Possibly related to the inbound dispatcher dropping the update before logging it.

3. Repeated topic:905 session resets prior to today

The agent transcript directory shows topic:905 has been auto-reset 3 times in 24 hours:

• c0ffbf21-...-topic-905.jsonl.reset.2026-06-08T13-05-18.913Z
• d8243339-...-topic-905.jsonl.reset.2026-06-08T23-56-15.247Z
• And again today (manual delete). Suggests this thread has chronic instability.

4. Stuck-session recovery right before the black hole started

2026-06-09T08:02:26 [diagnostic] stalled session: sessionId=d8243339-... sessionKey=agent:main:telegram:group:-100XXXXXXXXXX:topic:905 state=processing age=371s queueDepth=1 reason=active_work_without_progress classification=stalled_agent_run activeWorkKind=embedded_run
2026-06-09T08:02:26 [diagnostic] stuck session recovery: sessionId=d8243339-... sessionKey=agent:main:telegram:group:-100XXXXXXXXXX:topic:905 age=371s action=abort_embedded_run aborted=true drained=true
2026-06-09T08:02:26 [diagnostic] stuck session recovery outcome: status=aborted action=abort_embedded_run sessionId=d8243339-... sessionKey=agent:main:telegram:group:-100XXXXXXXXXX:topic:905

A stuck session recovery aborted the embedded run for topic:905 shortly before the black hole began. Hypothesis: the recovery path leaves residual state somewhere persistent (not the in-process Map) that causes future inbound updates for this exact (chatId, thread_id) to be dropped.

Repro shape

1. Have a Telegram forum group where one topic accumulates a stuck session that gets recovered via abort_embedded_run + the timed-out-spooled-handler path.
2. After recovery, send any user message to that topic.
3. Observe: Telegram acks the update, no Inbound message ... log line, agent never receives. Other topics in the same chat continue to work.

Workaround

Users have to abandon the affected thread and create a new one in the same forum group. Even fully removing the session entry + transcript + multiple gateway restarts does not restore inbound to the original thread.

Asks for the maintainer

1. Where is the persistent state that survives sessions.json deletion + restart and keys off (chatId, thread_id) to drop inbound updates for one specific topic? That's the mystery.
2. The sessions.resolve call using telegram:<chatId>:905 (without topic:) — what's the caller? It's a hint that some component constructs session keys without the thread segment.
3. Should abort_embedded_run recovery clear all persisted lane state for that thread, including any dedup / claim / message-cache entries that might key off thread_id alone?

Happy to provide more raw log slices, sqlite plugin-state dumps, or attempt patches if guided.