Bug: transient connection failures can leave Telegram requests without a final reply

[FrundlesTian]

Summary

A Claude run can complete while the user receives no final Telegram message, and some SDK stream disconnects are incorrectly accepted as successful runs.

Confirmed failure modes

1. Final Telegram replies do not retry transient NetworkError/TimedOut failures. The current HTML-to-plain-text fallback retries immediately, so all attempts can fail inside the same outage window. AIORateLimiter only retries RetryAfter.
2. The SDK receive loop can end without a ResultMessage; this is currently treated as success instead of a connection failure.
3. builder.proxy() configures the normal Bot request client, while long-polling getUpdates uses its own client and is not given get_updates_proxy().

Proposed fix

• Add a small shared Telegram send helper with bounded exponential backoff for transient transport failures, while keeping parse-mode fallback separate.
• Require a terminal ResultMessage; retry an empty/pre-output stream, but do not automatically replay a request after observable output/tool use because that could duplicate side effects.
• Apply an explicitly configured proxy to both Telegram request clients.
• Add regression tests for transient send recovery, terminal-message validation, and proxy wiring.

Out of scope

The global update lock currently serializes all users and can amplify a hung request. Converting it to per-session locking changes concurrency semantics and should be handled separately.

Related

• Add retry logic for transient network errors in Claude SDK calls #60
• Fix: Explicitly set proxy for httpx client to prevent connection pool corruption #166
• Polling stops permanently with "Pool timeout" after a getUpdates request is interrupted mid-flight #213
• The SDK boundary is almost entirely mocked, and claude_agent_sdk.testing only partly helps #234
• fix: say why a run stopped instead of reporting success #236
• fix: fall back when provider result is empty #240

[FrundlesTian]

I’m taking this. I’ll implement it on top of #236/#240, keep the retry policy side-effect-aware, add focused regression tests, and submit a stacked PR once the full test and lint suite is clean.