1d2e34c7eb
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 |
||
|---|---|---|
| .. | ||
| ADDING_A_PLATFORM.md | ||
| __init__.py | ||
| api_server.py | ||
| base.py | ||
| dingtalk.py | ||
| discord.py | ||
| email.py | ||
| feishu.py | ||
| homeassistant.py | ||
| matrix.py | ||
| mattermost.py | ||
| signal.py | ||
| slack.py | ||
| sms.py | ||
| telegram.py | ||
| telegram_network.py | ||
| webhook.py | ||
| wecom.py | ||
| whatsapp.py | ||