[Bug]: retry_request discards HTTP 429 rate-limit responses on retry exhaustion (raising bare RuntimeError) and crashes on standard HTTP-date Retry-After headers

[Preciousuche]

Duplicate check

• I searched the existing open and closed issues and this is not a duplicate.

AgentOS version or commit

2026.9.1

Area

Channel integration

Reproduction steps

Define a mock endpoint or handler that returns HTTP 429 with Retry-After:
python
import asyncio, httpx
from agentos.channels._util import retry_request
async def mock_endpoint(*args, **kwargs):
return httpx.Response(429, headers={"Retry-After": "0.1"}, json={"error": "rate_limited"})
async def main():
resp = await retry_request(mock_endpoint, max_retries=1, base_delay=0.1)
asyncio.run(main())
Observe the exception raised when retries are exhausted.
Alternatively, supply an RFC 7231 / RFC 9110 compliant HTTP-date header:
python
headers = {"Retry-After": "Wed, 21 Oct 2026 07:28:00 GMT"}

Expected behavior

When retries are exhausted on a 429 response, retry_request should return the httpx.Response object (matching how 5xx statuses behave) so callers (Slack, Discord, Webhook delivery) can access the status code, response headers, and downstream error body.
Retry-After should safely parse both integer/float seconds and HTTP-date strings without throwing an unhandled ValueError.

Actual behavior

On the final retry attempt (attempt == max_retries), the 429 branch executes await asyncio.sleep(retry_after); continue without checking attempt < max_retries. The loop terminates and falls through to raise last_exc or RuntimeError("retry_request exhausted"). Because last_exc is None, a bare RuntimeError is raised and the response is permanently discarded.
If a server responds with an HTTP-date format in Retry-After, float(resp.headers.get("Retry-After")) raises an unhandled ValueError: could not convert string to float: 'Wed, 21 Oct 2026 07:28:00 GMT', crashing immediately on attempt 0.

Environment

Windows 10 / Linux / macOS, Python 3.12+ (tested on Python 3.14.3 with uv)

[Preciousuche]

I am working on this

[andreapn]

Closing as a duplicate — both bugs are real and both are already tracked, one each.

Confirmed on main (5b740f3), src/agentos/channels/_util.py:274-304: the 429 branch at :286-290 has no attempt < max_retries guard (unlike the 5xx branch at :291), so on the final attempt it sleeps, continues, exits the loop, and hits raise last_exc or RuntimeError("retry_request exhausted") with last_exc still None — the httpx.Response is discarded. And float(resp.headers.get("Retry-After", ...)) at :287 raises ValueError on an RFC 9110 HTTP-date, which is a format servers are entitled to send.

Both are correctly diagnosed. They are just already filed:

• 429 discarded on exhaustion → [Bug]: retry_request sleeps on final 429 attempt and raises generic RuntimeError instead of returning Response #599, with PRs fix(channels): return 429 Response on final retry_request attempt instead of raising #602 and fix(channels): return Response on retry_request 429 exhaustion withou… #603 open
• Retry-After HTTP-date crash → [Bug]: retry_request misses ConnectTimeout/WriteTimeout and crashes on non-numeric Retry-After #642, with PRs fix(channels): catch all TimeoutException subclasses and safely parse Retry-After in retry_request #643 and fix(channels): catch ConnectTimeout/WriteTimeout and handle non-numeric Retry-After (#642) #645 open (that issue also covers the related ConnectTimeout/WriteTimeout/PoolTimeout gap in the except clause at :297, which this report does not mention and which is worth fixing in the same pass)

Nothing here is wrong — the analysis is good and the HTTP-date repro is a useful addition. Please add it to #642 rather than tracking it separately, so the four open PRs converge on two issues instead of three.