#10865: telegram: fast-ACK webhook and retry bind on EADDRINUSE
channel: telegram
stale
Cluster:
Webhook Configuration and Resilience
### Problem
Telegram webhook requests can time out when agent/tool processing is slow (10–60s+), leading to delayed updates, retries, and user-facing “Telegram Web not updating / bot not responding”.
Observed errors:
- webhook handler timeout at 60s
- “Bot not initialized!” when handling updates manually
- crash loop on restart due to port reuse: listen EADDRINUSE 0.0.0.0:8787
### Changes
- Fast-ACK Telegram webhook: read request body, respond 200 OK immediately, then process update asynchronously via bot.handleUpdate(update).
- Call await bot.init() to ensure bot info is available when handling updates manually.
- Add retry/backoff for server.listen when EADDRINUSE occurs (reduces crash loops during rapid restarts / port not released yet).
### Tests
- Updated src/telegram/webhook.test.ts to assert:
- HTTP POST returns 200
- bot.init() called
- bot.handleUpdate() invoked asynchronously
<!-- greptile_comment -->
<h2>Greptile Overview</h2>
<h3>Greptile Summary</h3>
- Reworks Telegram webhook handling to “fast-ACK”: read request body, respond 200, then process updates asynchronously via `bot.handleUpdate()`.
- Ensures bot metadata is available for manual update processing by calling `await bot.init()`.
- Adds `listenWithRetry` retry/backoff logic when binding the webhook HTTP server fails with `EADDRINUSE`.
- Updates webhook tests to assert immediate 200 response and that `init()`/`handleUpdate()` are invoked.
<h3>Confidence Score: 3/5</h3>
- Reasonably safe, but has a couple of correctness issues that can break webhook behavior in common configurations.
- Fast-ACK + async handling is a good direction, but the current response-writing flow can race into double responses, and the webhook URL can be incorrect when `port=0`/`host=0.0.0.0` because it’s computed before binding. Both should be addressed before merge.
- src/telegram/webhook.ts
<!-- greptile_other_comments_section -->
<sub>(2/5) Greptile learns from your feedback when you react with thumbs up/down!</sub>
<!-- /greptile_comment -->
Most Similar PRs
#22694: telegram: stabilize multi-account webhook mode
by Dongik · 2026-02-21
78.2%
#5561: fix(telegram): auto-restart on timeout + lower API timeout to 60s
by jesseproudman · 2026-01-31
78.2%
#14741: feat: telegram resilience utilities
by kalachbeg · 2026-02-12
78.0%
#7754: fix(telegram): configurable webhook timeout
by djmango · 2026-02-03
76.6%
#6463: fix(telegram): improve timeout handling and prevent channel exits
by ai-fanatic · 2026-02-01
76.2%
#3186: fix(telegram): sanitize update offset + lock polling
by daxiong888 · 2026-01-28
75.6%
#17918: fix(telegram): start webhook listener before setWebhook + forward w...
by Glucksberg · 2026-02-16
75.3%
#8166: fix(telegram): lifecycle fixes for duplicate messages and auto-reco...
by cheenu1092-oss · 2026-02-03
74.4%
#20420: Telegram webhook listener to use the gateway's HTTP server instead ...
by kesor · 2026-02-18
74.2%
#11347: fix: scope Telegram update offset to bot token
by anooprdawar · 2026-02-07
73.6%