fix(telegram): bound and refresh general httpx pool

[chengnas]

Summary

• bound Telegram HTTPXRequest pools to a smaller default and shared keepalive limits
• refresh the general Bot API request pool after polling reconnects and send-path network errors
• add regression tests for bounded HTTPX limits and general-pool refresh before retrying sends

Motivation

Telegram's python-telegram-bot integration keeps separate httpx request pools for polling (Bot._request[0]) and general Bot API calls (Bot._request[1]). The adapter already refreshed the polling pool after reconnects, but send/edit/set-command calls can still get stuck behind stale half-closed connections in the general pool, especially when routed through HTTP proxies.

The old default pool size of 512 also makes stale connections accumulate for a long time before surfacing as pool exhaustion. This change keeps the pool bounded and gives keepalive sockets a short lifetime.

Tests

• python -m py_compile gateway/platforms/telegram.py tests/gateway/test_telegram_conflict.py tests/gateway/test_telegram_thread_fallback.py
• python -m pytest tests/gateway/test_telegram_conflict.py tests/gateway/test_telegram_thread_fallback.py

Locally the targeted tests pass: 56 passed.

[liuhao1024]

Verification Review

Well-structured pool management fix. Observations:

1. Default pool size 512 → 20: This is a significant reduction for the HERMES_TELEGRAM_HTTP_POOL_SIZE default. For most self-hosted users this is fine (20 concurrent connections is generous for a single bot). High-traffic bots with webhook-mode multi-chat workloads may hit pool saturation sooner, but the env-var override provides an escape hatch.

2. platform_httpx_limits() integration is safe: The getattr(..., None) guards handle the case where platform_httpx_limits() returns None (no custom limits configured) — httpx_kwargs stays empty and httpx uses its defaults. The min(max_keepalive, connection_pool_size) ensures keepalive never exceeds total pool size.

3. General pool drain on send-path network errors: The _drain_general_connections() calls before retry in send() and after polling reconnect address the root cause (stale half-closed sockets occupying pool slots). The _drain_request_connections(request_index, label) refactor keeps the logic DRY.

4. keepalive_expiry=2.0: Short keepalive reduces idle socket accumulation. Good for proxy-heavy setups (sing-box, etc.) where connections go stale frequently.

5. Test coverage is solid: test_connect_uses_bounded_httpx_limits verifies the limits object is passed through to both request clients. test_drain_general_connections_resets_general_request_only verifies isolation between polling and general pools. test_send_refreshes_general_pool_before_retrying_network_error verifies the send-path drain.

LGTM.

[teknium1]

Thanks for the diagnosis and targeted coverage. This is an automated hermes-sweeper review; current main now provides the underlying recovery more narrowly and safely.

• plugins/platforms/telegram/adapter.py:3078-3179 wires bounded keepalive limits into all Telegram request-construction paths; this shipped in 4b7f3826 (fix(telegram): wire keepalive limits into general request pool to fix CLOSE_WAIT fd leak (#31599) #51541).
• plugins/platforms/telegram/adapter.py:1902-1937 serializes refresh of PTB's general _request[1] pool, and :3796-3813 invokes it only for a confirmed pool timeout before retrying; this shipped in 7e2ca7f68 via fix(telegram): drain general send pool on pool timeout before retry (#53524) #54121.
• tests/gateway/test_telegram_thread_fallback.py:1418-1454 covers the general-pool-only recovery contract.
• The later 01ee312de follow-up also fixes the fallback-transport limits case that this older diff could not cover correctly.

The Telegram adapter has since moved to plugins/platforms/telegram/adapter.py, so this branch's gateway/platforms/telegram.py patch is no longer salvageable as-is.