OpenClaw Main Fixes Telegram Topic Policy Bypass and Restart Replays

OpenClaw has merged a material Telegram reliability and authorization wave. Reaction notifications in forum groups now follow the topic of the reacted message instead of being treated as General topic 1; polling progress no longer advances durably before its state write succeeds; and outbound delivery correlation follows the topic explicitly selected for a send.

These are main changes, not evidence of inclusion in an installed package. Forum-topic operators and any automation with side effects should prioritize a containing build and reconcile older restart windows carefully.

Reactions were taking the wrong authorization route

Telegram’s MessageReactionUpdated event omits message_thread_id. Before PR #116380, OpenClaw treated every forum reaction as General topic 1. That could bypass the reacted topic’s enabled, agentId, allowlist, binding and session decisions.

The repair recovers provider-observed topic context from the bounded message cache before authorization, then routes the event through the same conversation resolver as an ordinary topic message. If the topic is unknown, OpenClaw drops the reaction with a bounded thread-context-unavailable warning rather than guessing General.

The change also serializes a message and its reaction at the exact-message boundary, closing the race where the reaction arrived before topic context entered the cache without serializing unrelated topics.

Interpretation: missing transport metadata cannot authorize a fallback route. When OpenClaw cannot prove the original topic, dropping a low-value reaction is safer than delivering it into a different agent and policy domain.

A failed offset write could replay completed updates

PR #110068 fixes a different durability fault. A transient update-offset persistence failure could still advance the monitor’s in-memory watermark. The process continued, but the durable watermark stayed stale; after restart, Telegram could replay updates that had already produced replies or tool side effects.

The new owner tracks accepted progress separately from committed progress. Only a successful state-store write advances the committed watermark. Writes coalesce behind a monotonic highest-pending target and retry with bounded backoff, while isolated polling keeps its committed SQLite spool as the worker acknowledgement boundary.

Completed spool tombstones remain authoritative, so even a stale provider replay should not execute the same durable item twice.

Do not read this as a universal exactly-once guarantee. External side effects still need idempotency keys and reconciliation because failures can occur after provider execution but before local completion is recorded.

Explicit topic sends now produce authoritative receipts

PR #117229 repairs delivery correlation for messages, polls and stickers sent to an explicitly selected topic. A stale topic embedded elsewhere in the target could previously win when OpenClaw recorded the receipt, leaving the matching inbound event falsely undelivered even though Telegram visibly accepted the send.

False non-delivery is dangerous when a retry controller or agent responds by sending again. The explicit send selection is now the authoritative topic fact.

PR #107105 also makes degraded inline keyboards visible. Telegram rejects callback_data over 64 UTF-8 bytes; when an invalid control is omitted, the tool result now tells the agent rather than returning a bare success that implies every requested button shipped.

Staging matrix

Use a disposable forum and harmless tools:

1. give two topics visibly different agent, allowlist or enabled policy;
2. react to a bot message in the restricted topic and prove the event stays in that topic;
3. clear the bounded context fixture and prove an unknown-topic reaction is dropped, not routed to General;
4. inject one offset-store failure, process a unique update, restart and prove its handler runs once;
5. send a message, poll and sticker to an explicit topic while a stale topic is present in the target fixture;
6. verify each receipt correlates to the explicit topic; and
7. request an oversized inline callback and require visible degradation plus a readable fallback.

Never test replay with payments, destructive commands or real recipients. A duplicate Telegram update may repeat tool effects even when the chat reply itself is easy to delete.

Incident response

For suspected pre-fix duplication, preserve the Telegram update ID, account identity, accepted and durable offset evidence, spool/tombstone state, session key and external tool receipt. Reconcile the side-effect target before replaying anything.

For suspected reaction misrouting, inspect the reacted message’s provider-observed topic and compare it with the session and agent that handled the notification. Do not rely on General-topic transcript order alone.

Evidence and limits

Official merged PR, commit and documentation records establish the defects and repairs. The forum-routing PR includes upstream real-Telegram proof for a known topic and fail-closed unknown-topic case; the offset PR reports focused durability tests and a real-user E2E. OpenClaw Academy did not connect a Telegram account or induce a live state-store outage.

Relevant collector IDs include 37940/37916/37939, 37947/37921, 38089/38026 and 38092/38064.

Bottom line

A Telegram forum topic is an authorization and session boundary, not presentation metadata. Adopt a containing build only after proving reactions cannot fall into General, polling restarts cannot replay completed work, and explicit-topic sends produce receipts for the topic that actually received them.