Summary

Telegram forum-topic messages can be permanently lost in a specific narrow window: openclaw acknowledges the inbound update_id to Telegram before the assistant's final outbound sendMessage has confirmed delivery. If the gateway is interrupted (watchdog restart, OOM kill, intentional systemctl restart, crash) between those two events, the new gateway never reprocesses the message — Telegram considers it delivered (offset advanced past it) and the user never sees a reply.

This is essentially the same symptom @bubucilo reported in #76554 (closed by maintainer 2026-05-03 16:01 UTC without an explicit resolution comment), but I'd like to file it again with a fresh production reproduction and a focused architectural ask, because the acked-vs-delivered race appears to be a structural issue independent of the 5.2-specific Telegram polling regression that's already merged in main (per #76735 / #76388).

Reproduction (verbatim from production)

• openclaw 2026.4.29 (a448042) — pinned here because the 5.2 upgrade path is blocked by externalized-plugin install issues (see #76586).
• Linode VPS, Singapore region.
• Telegram supergroup -1003888407906, Invest topic topic:31. Session e856c600-78b6-4035-8eff-d792002e3ba2-topic-31.
• The trigger is any gateway restart that interrupts the window between assistant-final-write and outbound-send. The specific trigger in our case happened to be a systemctl --user restart openclaw-gateway, but the same race fires on openclaw doctor --fix, openclaw update, OOM kill, segfault, or any other restart path. Restart frequency varies by environment, but the race itself is environment-independent.

Timeline (2026-05-03)

16:01:46  user → topic:31  "分析前面三支 etf 的价值"  (Telegram update_id 79669836)
16:02:43  session.jsonl: user message recorded; embedded run dispatched
            → at this point Telegram offset has already been advanced
              past 79669836 (openclaw's poller acks long-poll batches eagerly)
16:03:55  session.jsonl: assistant final text written
            "Got it — the original post by @tychozzz lists 5 ETFs he's DCA-ing,
             and 前面三支 = SMH, DRAM, BOTZ. Let me pull current data on all three."
            (no sendMessage logged yet — outbound queue still pending)
16:03:45  systemctl --user restart openclaw-gateway issued
            (in our case from a periodic health check; could equally be
             openclaw update, openclaw doctor --fix, OOM, or operator action)
16:04:20  Old gateway shutdown completes; new gateway PID 391548 starts
            → outbound queue from old PID is gone
            → Telegram offset is past 79669836, so new gateway does not see this update again
16:10:50  New gateway processes a different topic (topic:1) — 8 sendMessage events,
            none for topic:31

User waits, sees nothing in topic:31, eventually re-sends the prompt manually.

Diagnostic confirmation

session.jsonl for topic:31 contains the assistant text written at 16:03:55. journalctl --user -u openclaw-gateway.service from 16:03 to current contains zero [telegram] sendMessage ok chat=-1003888407906 message=... whose message_thread_id resolves to topic 31. The offset file ~/.openclaw/telegram/update-offset-default.json advanced past 79669836, so the new gateway will never re-fetch that user message.

This is a structural data loss: the user prompt was processed, the assistant generated a reply, the reply was written to the local transcript, and the user has no way to receive it.

What's distinct from already-closed reports

• #76554 (closed 2026-05-03 16:01:59 UTC by maintainer, no resolution comment): same end-state symptom (transcript written, channel silent). That report was on 2026.5.2 and didn't tie the failure to a specific interruption trigger; OP @bubucilo described "many topics" silently failing without correlating to gateway lifecycle. Our report ties the loss to a deterministic trigger (any gateway restart between assistant-final-write and outbound-send) which is reproducible on demand.
• #76388 (closed 2026-05-03, "fixed in main" via #76735): addresses Telegram polling startup not entering long-poll on high-RTT hosts. That's an upstream bug (different code path); this issue is about the downstream delivery handoff.
• #50716 / #51659 / #66459 (older, all open or closed without fix): describe the same symptom historically. Suggests this is a long-standing race that hasn't been structurally addressed.

Suggested fix direction

The root issue is that openclaw acks the Telegram update_id (advances lastUpdateId in the offset store) when the embedded run starts processing the message, not when the assistant's final outbound sendMessage confirms delivery. Two structural fixes that would prevent the loss:

Option A: defer offset advancement until sendMessage confirms

Hold the inbound update_id un-acked until the corresponding outbound sendMessage returns 200 OK. If the run is interrupted, the next gateway boot's getUpdates will receive the same update again and re-process it. Cost: 1 extra round-trip on slow turns; user might get a duplicate response if a turn does deliver but the offset write fails (need idempotency at the channel-send layer).

Option B: persist the outbound queue across restart

After the assistant final text is written to the transcript, queue the channel-send to a durable disk-backed queue keyed on session+turn. On gateway restart, drain the queue before resuming polling. Cost: more state to manage; potential duplicate sends if a previous gateway both queued AND sent before crash. Idempotency on the channel side (Telegram + a turn-id watermark) is needed.

Option A is cheaper to implement and matches how most polling consumers handle at-least-once delivery (don't ack until processed). Option B is more general (handles other channels too) but requires more infrastructure.

The current behavior is at-most-once, which is the wrong default for this class of payload (user-visible AI replies that the user may have spent significant time formulating).

Environment

• openclaw: 2026.4.29 (a448042)
• OS: Linux (Linode VPS, Singapore region)
• Telegram channel mode: long polling
• Affected topic types: forum topics specifically (DM + non-forum group chats less affected because they don't have the same offset-vs-thread-id state to lose)
• Restart triggers that reproduce the race in production: openclaw doctor --fix (which itself does a systemctl restart), openclaw update (without --no-restart), manual systemctl restart for hook reloads, OOM, and any process-level health-check that wraps systemctl restart — the bug is in openclaw's ack-vs-deliver ordering, not in any of these triggers individually.

Happy to provide stability bundle, full session JSONL for the 2026-05-03 16:01 incident, the offset store before/after, or a CPU profile.