Repository navigation
Idempotent retry helper ignores HTTP-date Retry-After values #134
Description
Bug
DefaultApi.create_notification_with_retry ignores HTTP-date Retry-After headers and uses exponential backoff, even when the date asks the client to wait longer. HTTP-date is a valid Retry-After form under RFC 9110 section 10.2.3: https://www.rfc-editor.org/rfc/rfc9110.html#name-retry-after
Local reproduction
With a mocked clock at 2027-01-01 00:00:00 UTC and a mocked 503 response carrying Retry-After: Fri, 01 Jan 2027 00:00:30 GMT, the public helper calls time.sleep(1.0) rather than waiting 30 seconds. A past HTTP-date also causes a fallback sleep when it should allow an immediate retry. 429 responses use the same path.
The helper currently tries only float(retry_after). Proposed fix: preserve numeric handling and use the standard-library date parser with explicit UTC handling for HTTP dates, falling back to the existing exponential delay on malformed values. Add tests through the public helper for both retryable statuses, modern/obsolete HTTP-date formats, past dates, and numeric/missing/malformed controls. Preserve the same idempotency key on retries.
Python 3.12, SDK 5.18.0, local mocked API responses, clock, and sleep only. No real notification was sent. AI assistance: OpenAI Codex.
Activity
sherwinski commentedon Oct 28, 2026
Hey @Kayvan-Zahiri, thanks for the detailed report and the PR.
While your analysis is correct, RFC 9110 allows an
HTTP-datein Retry-After and the helper only parses delay-seconds, we are going to close this as won't fix because the OneSignal API never sends the HTTP-date form. Additionally, our public docs state that the header is expressed as a number of seconds. If a non-numeric value were to be sent, the helper falls back to exponential backoff.