Skip to content

Observable Rate Limit Info - #75

Open
pyrogenic wants to merge 2 commits into
aknorw:masterfrom
pyrogenic:feat/rate-limit-observability
Open

pyrogenic wants to merge 2 commits into
aknorw:masterfrom
pyrogenic:feat/rate-limit-observability

Conversation

@pyrogenic

Copy link
Copy Markdown

The Discogs API returns rate limit info on every response, but a consumer has no way to read them. (The values are consumed internally by maybeUpdateLimiter.) This change allows an app to show a user their remaining budget or pace its requests intentionally based on the real budget numbers.

Adds an optional onRateLimit callback invoked for each response. It fires before the status check so it can report on errors, since a 429 is exactly when it's most interesting. It swallows callback exceptions so it won't fail requests. (Absent or malformed headers are undefined rather than NaN, which cleans up some existing limiter logic.)

Adds DiscogsError.retryAfter?, parsed from Retry-After. This lets a client wait out a 429 for the right length of time instead of a guessing. The constructor argument is optional, so no existing call site changes.

I chose a callback to avoid adding fields to every method's return type.

pyrogenic and others added 2 commits August 22, 2026 00:20
The Discogs API returns `X-Discogs-Ratelimit`, `-Used` and
`-Remaining` on every response, but a consumer had no way to
read them: `maybeUpdateLimiter` consumed two of the three to
retune the internal limiter and dropped them, and `-Used` was
never read at all. An app that wants to show a user their
remaining budget, or pace itself off it rather than guessing,
had nothing to work with.

Adds `onRateLimit`, called with a `RateLimitInfo` for every
response. It fires before the status checks, so it reports on
error responses too -- a 429 is precisely when those numbers
matter most. A throwing callback is swallowed; a consumer's
reporting hook should not be able to fail their request.

Absent or malformed headers now yield undefined rather than
NaN, which also tidies the existing limiter logic.

`DiscogsError` gains `retryAfter`, parsed from `Retry-After`,
so a 429 can be waited out for the right length of time
instead of a guessed one. The constructor argument is
optional, so no existing call site changes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@pyrogenic pyrogenic changed the title Feat/rate limit observability Aug 23, 2026
@pyrogenic
pyrogenic marked this pull request as ready for review August 23, 2026 03:02

This branch has not been deployed

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

Labels

None yet

1 participant