fix(telegram): break infinite 409 conflict loop by not resetting counter on polling success (#63724)

[webtecnica]

Fixes #63724. The conflict counter was reset to 0 on every successful start_polling(), preventing the fatal path (count > 5) from ever being reached. Now uses monotonic timestamp to track recovery instead.

[alt-glitch]

This was generated by AI during triage.

Competing fix for #63724 (Telegram 409 infinite loop, family anchor #58484) — three open PRs, three different mechanisms:

• fix(telegram): keep polling conflict counter across successful retries #58492 (earliest/canonical): stop resetting the counter across successful retries.
• fix(telegram): escalate persistent 409 Conflict to fatal via wall-clock gate #64064: immutable wall-clock gate, short-circuit to fatal after 300s.
• fix(telegram): break infinite 409 conflict loop by not resetting counter on polling success (#63724) #64082 (this PR): 60s cooldown-based counter decay, only reset the counter if the last successful recovery was >60s ago.

Same root cause, distinct approaches. Linking them so a maintainer can pick one; not marking duplicate. related: #58492, #64064, #63724, #58484.

[tonydwb]

Code Review Summary

Verdict: Comment (token read-only)

PR 64082: fix(telegram): break infinite 409 conflict loop by not resetting counter on polling success

Correctness ✅

• Adds time-based counter decay to _handle_polling_conflict(): if the last successful start_polling() was more than 60 seconds ago, the counter is reset on a new 409.
• Tracks _polling_conflict_last_ok_time to distinguish rapid-fire 409s (same episode, keep counter accumulated) from genuinely new conflicts.
• On successful recovery, records last_ok_time but does NOT reset counter — ensuring the retry ladder eventually escalates to fatal.
• Addresses #63724 infinite loop where every successful recovery reset the counter to 0 and a fresh 409 immediately fired again.

No issues found.

---

Reviewed by Hermes Agent

[tonydwb]

Code Review Summary

Verdict: Comment (token read-only)

PR 64082: fix(telegram): break infinite 409 conflict loop by not resetting counter on polling success

Correctness ✅

• Adds time-based counter decay to _handle_polling_conflict(): if the last successful start_polling() was more than 60 seconds ago, the counter is reset on a new 409.
• Tracks _polling_conflict_last_ok_time to distinguish rapid-fire 409s (same episode, keep counter accumulated) from genuinely new conflicts.
• On successful recovery, records last_ok_time but does NOT reset counter — ensuring the retry ladder eventually escalates to fatal.
• Addresses #63724 infinite loop where every successful recovery reset the counter to 0 and a fresh 409 immediately fired again.

No issues found.

---

Reviewed by Hermes Agent

[tonydwb]

Code Review Summary

Verdict: Comment

Changes

Telegram polling conflict recovery: time-based counter decay prevents infinite 409 loops (#63724). The counter is now reset only if the last successful start_polling was more than 60 seconds ago, preventing rapid-fire 409s from masking a persistent conflict.

Assessment

• Correctness: Well-reasoned fix. Without this, every successful start_polling after a 409 would reset the counter, and a persistent 409 would loop forever. Now the counter is only reset after COOLDOWN_SECONDS of successful polling.
• Code quality: Clear comments explaining the guard against infinite loops. The CONFLICT_COOLDOWN_SECONDS constant is well-documented.
• No debug artifacts.

---

Reviewed by Hermes Agent

[webtecnica]

Rebased onto upstream/main (46e87b1).