Problem
The backend returns the following headers on 429 responses:
X-RateLimit-Limit-PerMinute
X-RateLimit-Remaining-PerMinute
X-RateLimit-Limit-PerDay
X-RateLimit-Remaining-PerDay
Retry-After
The SDK currently only parses Retry-After and discards the rest. Callers have no way to know which limit was hit or what the limit value is, making it impossible to implement informed backoff or meaningful error messages.
Proposed Behaviour
Parse all rate limit response headers and expose them as fields on RateLimitError.
} catch (e) {
if (e instanceof RateLimitError) {
console.log(e.retryAfter) // seconds to wait
console.log(e.limitPerMinute) // per-minute cap, or undefined
console.log(e.limitPerDay) // per-day cap, or undefined
}
}
Files to Modify
| File |
Change |
src/errors.ts |
Add limitPerMinute, limitPerDay fields to RateLimitError |
src/client.ts |
Parse additional headers in handleErrorResponse |
Acceptance Criteria
Problem
The backend returns the following headers on 429 responses:
X-RateLimit-Limit-PerMinuteX-RateLimit-Remaining-PerMinuteX-RateLimit-Limit-PerDayX-RateLimit-Remaining-PerDayRetry-AfterThe SDK currently only parses
Retry-Afterand discards the rest. Callers have no way to know which limit was hit or what the limit value is, making it impossible to implement informed backoff or meaningful error messages.Proposed Behaviour
Parse all rate limit response headers and expose them as fields on
RateLimitError.Files to Modify
src/errors.tslimitPerMinute,limitPerDayfields toRateLimitErrorsrc/client.tshandleErrorResponseAcceptance Criteria
RateLimitError.retryAfterbehaviour is unchangedRateLimitError.limitPerMinuteset when header is presentRateLimitError.limitPerDayset when header is presentundefinedwhen the corresponding header is absent