Skip to content

fix: harden Telegram polling handoffs and flood-control sends#5201

Closed
kshitijk4poor wants to merge 1 commit into
NousResearch:mainfrom
kshitijk4poor:codex/telegram-upstream-parity
Closed

fix: harden Telegram polling handoffs and flood-control sends#5201
kshitijk4poor wants to merge 1 commit into
NousResearch:mainfrom
kshitijk4poor:codex/telegram-upstream-parity

Conversation

@kshitijk4poor

@kshitijk4poor kshitijk4poor commented Apr 5, 2026

Copy link
Copy Markdown
Collaborator

What changed

This narrows in on two Telegram gateway failure modes found during a review of Hermes's Telegram adapter:

  1. Polling mode now clears any stale Telegram webhook before starting getUpdates.
  2. Outbound send() now backs off and retries on Telegram flood-control / retry_after responses instead of failing immediately.
  3. Regression tests cover both behaviors.

Why

This review surfaced two concrete gaps that were small enough to fix without broadening the PR scope:

  • Webhook to polling handoffs can leave Telegram still configured for webhooks, which means polling starts but does not reliably receive updates.
  • Temporary Telegram flood control can cause message delivery failures even when the correct behavior is to wait and retry.

This PR fixes those narrow issues while keeping the patch minimal against upstream/main.

Impact

  • Safer Telegram transport-mode transitions for self-hosted deployments that switch between webhook and polling.
  • Better resilience for streamed replies, tool progress messages, and other outbound Telegram sends during brief rate limits.
  • No broader routing, session, or policy changes.

Validation

  • uv run --extra dev pytest tests/gateway/test_telegram_* -q

Telegram polling can inherit a stale webhook registration when a deployment
switches transport modes, which leaves getUpdates idle even though the gateway
starts cleanly. Outbound send also treats Telegram retry_after responses as
terminal errors, so brief flood control can drop tool progress and replies.

Constraint: Keep the PR narrowly scoped to upstream/main Telegram adapter behavior
Rejected: Port OpenClaw's broader polling supervisor and offset persistence | too broad for an isolated fix PR
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Polling mode should clear webhook state before starting getUpdates, and send-path retry logic must distinguish flood control from timeouts
Tested: uv run --extra dev pytest tests/gateway/test_telegram_* -q
Not-tested: Live Telegram webhook-to-polling migration and real Bot API 429 behavior
@kshitijk4poor kshitijk4poor changed the title [codex] Harden Telegram polling handoffs and flood-control sends fix: harden Telegram polling handoffs and flood-control sends Apr 5, 2026
@kshitijk4poor kshitijk4poor marked this pull request as ready for review April 5, 2026 09:26
@teknium1

teknium1 commented Apr 5, 2026

Copy link
Copy Markdown
Contributor

Merged via PR #5288 (consolidated bugfix salvage). Your commit(s) were cherry-picked onto current main with your authorship preserved in git log. Thanks @kshitijk4poor for the fix!

@teknium1 teknium1 closed this Apr 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants