Issue Station
Sign In
Tools hereToolbox

hermes - 💡(How to fix) Fix [Bug] Telegram: Pool timeout causes silent send failures — no retry or fallback on exhausted general pool

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

Error from gateway.log:

  • The error is caught, logged as , and the message is dropped silently

Root Cause

The Telegram adapter's httpx connection pool (, via ) can become saturated under the following conditions:

  1. Temporary network latency spikes (proxy/firewall packet loss)
  2. Slow Telegram API responses during high traffic periods
  3. Connection pool exhaustion during or after reconnect storms

When the general pool ( in PTB terminology) is saturated:

  • New / calls immediately fail with
  • The error is caught, logged as , and the message is dropped silently
  • The flag (from PR #31441) is only set during reconnect events — not on general pool exhaustion — so it provides no protection for this case
  • The existing of 8s is already an improvement over PTB's 1s default, but when the pool is fully occupied, any new request times out immediately rather than waiting or retrying

Existing mitigations that don't fully cover this:

  • PR #6897 (closed, merged): increased pool timeout defaults but did not add retry/fallback
  • PR #31441 (closed, merged): added fallback, but only triggered by reconnect events, not by send-side pool exhaustion
  • PR #21548 (open, P1): probes the correct pool for wedge detection, but is still awaiting merge

Fix Action

Fix / Workaround

Existing mitigations that don't fully cover this:

  • PR #6897 (closed, merged): increased pool timeout defaults but did not add retry/fallback
  • PR #31441 (closed, merged): added fallback, but only triggered by reconnect events, not by send-side pool exhaustion
  • PR #21548 (open, P1): probes the correct pool for wedge detection, but is still awaiting merge
RAW_BUFFERClick to expand / collapse

Bug Description

Error from gateway.log:

Frequency: Recurring — observed multiple times on 2026-05-23 and 2026-05-30.

Affected version: Hermes Agent v0.15.1 (2026.5.29), Windows 10

Root Cause Analysis

The Telegram adapter's httpx connection pool (, via ) can become saturated under the following conditions:

  1. Temporary network latency spikes (proxy/firewall packet loss)
  2. Slow Telegram API responses during high traffic periods
  3. Connection pool exhaustion during or after reconnect storms

When the general pool ( in PTB terminology) is saturated:

  • New / calls immediately fail with
  • The error is caught, logged as , and the message is dropped silently
  • The flag (from PR #31441) is only set during reconnect events — not on general pool exhaustion — so it provides no protection for this case
  • The existing of 8s is already an improvement over PTB's 1s default, but when the pool is fully occupied, any new request times out immediately rather than waiting or retrying

Existing mitigations that don't fully cover this:

  • PR #6897 (closed, merged): increased pool timeout defaults but did not add retry/fallback
  • PR #31441 (closed, merged): added fallback, but only triggered by reconnect events, not by send-side pool exhaustion
  • PR #21548 (open, P1): probes the correct pool for wedge detection, but is still awaiting merge

Expected Behavior

When the general pool is exhausted during a send operation:

  1. Immediate retry — try once more on the same pool (same behavior as all retryable errors)
  2. Fallback to standalone HTTP — if retry fails, fall back to a fresh HTTP session (like the path does during reconnect) rather than dropping the message
  3. Exponential back-off — respect Telegram's 429 rate-limit headers rather than spinning

Impact

  • User-facing silent drops: Trade confirmations, cron reports, and agent responses silently fail to deliver
  • No user notification: The message only appears in gateway logs, not to the user
  • Requires manual intervention: Gateway must be manually restarted to clear the wedged pool state in some cases

Environment

  • OS: Windows 10 (x86_64)
  • Hermes Agent: v0.15.1 (2026.5.29)
  • Python: 3.11.15
  • Platform: Telegram (bot token configured, polling mode)
  • Related logs: lines showing

Related Issues / PRs

  • #6897 (closed, merged): fix(gateway/telegram): reduce HTTPX pool-timeout failures during reconnect
  • #31441 (closed, merged): fix(telegram): detect wedged send path after reconnect storms
  • #21548 (open, P1): fix(gateway): detect Telegram polling-pool wedges via correct pool
  • #32003 (open): fix(gateway): bound Telegram general pool on proxy path to cap fd leak

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - 💡(How to fix) Fix [Bug] Telegram: Pool timeout causes silent send failures — no retry or fallback on exhausted general pool