polling-bot-offset-freeze-diagnosislisted

# Polling-Bot Offset-Freeze Diagnosis ## When to use A long-poll bot (Telegram `getUpdates`, or any single-consumer poll API) suddenly re-delivers a backlog of old messages, or the stored offset hasn't moved in days. Root cause is almost always **two consumers sharing one token**: each `getUpdates` call ACKs only what *it* sees, so neither advances the shared offset past the other's reads. The backlog never clears and re-floods on every trigger. Distinct from backlog/age-filter issues (`polling-bot-backlog-diagnosis`, `polling-bot-age-filter-fix`) — here the offset is *frozen*, not just old. Fixing the age filter alone will not unstick a frozen offset. ## Diagnostic steps (verify live state before changing anything) 1. **Read prior incident notes first.** Check memweave and any gitignored local-only incident forensics before touching code — the freeze may already be characterized. 2. **Confirm the offset is actually frozen.** Read the persisted offset file and its mtime. A days-old mtime with a live cron means the value isn't advancing: ```bash stat -c '%y' state/<offset-file> # last write time cat state/<offset-file> # current offset value ``` 3. **Confirm the re-skip loop in the log.** A fresh log timestamp showing the poller skipping the same stale backlog every interval (not advancing) confirms the bot re-reads and re-discards the same updates each run. 4. **Find the competing consumers.** Enumerate every job that calls