Skip to content

Comments

fix: use relative delay for Retry-After header on 429#421

Open
apoorvdarshan wants to merge 1 commit intoopenclaw:mainfrom
apoorvdarshan:fix/retry-after-relative-delay
Open

fix: use relative delay for Retry-After header on 429#421
apoorvdarshan wants to merge 1 commit intoopenclaw:mainfrom
apoorvdarshan:fix/retry-after-relative-delay

Conversation

@apoorvdarshan
Copy link

@apoorvdarshan apoorvdarshan commented Feb 18, 2026

Summary

  • Fixes Retry-After header on 429 responses to emit a relative delay in seconds (per RFC 9110 §10.2.3) instead of an absolute Unix epoch timestamp
  • Previously, Retry-After was set to e.g. 1771404540 (epoch seconds), causing clients that treat it as delay-seconds to wait ~56 years
  • X-RateLimit-Reset remains as epoch seconds (standard convention for that header)
  • Adds a regression test asserting Retry-After is a small relative value

Closes #407

Test plan

  • Existing tests pass (vitest run convex/httpApiV1.handlers.test.ts — 40/40)
  • New test "429 Retry-After is a relative delay, not an absolute epoch" verifies the header value is between 1–120 seconds

Greptile Summary

Fixes the Retry-After header on 429 responses to emit a relative delay in seconds (per RFC 9110 §10.2.3) instead of the raw resetAt epoch timestamp. Previously, clients treating the value as delay-seconds would wait ~56 years. The fix computes the delta between the rate-limit reset time and the current time, with a Math.max(1, ...) floor. X-RateLimit-Reset correctly continues to use epoch seconds. A regression test verifies the header value falls within 1–120 seconds.

Confidence Score: 5/5

  • This PR is safe to merge — it's a targeted one-line fix with a clear regression test.
  • The change is minimal (one new line, one modified line) and directly addresses a clear bug. The relative delay computation is correct: resetAt is an epoch-ms value from the rate limiter, divided by 1000 to get epoch-seconds, then subtracted from the current epoch-seconds. The Math.max(1, ...) guard handles edge cases where the reset window has already passed. The regression test appropriately validates the fix using the existing mock infrastructure.
  • No files require special attention.

Last reviewed commit: 6c87964

(2/5) Greptile learns from your feedback when you react with thumbs up/down!

Context used:

  • Context from dashboard - AGENTS.md (source)

Retry-After was set to an absolute Unix epoch timestamp (e.g. 1771404540),
which violates RFC 9110 §10.2.3. Clients treating it as delay-seconds
would wait ~56 years. Now emits the actual seconds until reset.

Closes openclaw#407
@vercel
Copy link
Contributor

vercel bot commented Feb 18, 2026

@apoorvdarshan is attempting to deploy a commit to the Amantus Machina Team on Vercel.

A member of the Team first needs to authorize it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug: Retry-After uses absolute Unix epoch on 429, instead of retry delay seconds

1 participant