Repository navigation
A GitHub secondary rate limit pauses polling for 10 minutes instead of the ~60 s Retry-After, and an Azure DevOps 429's Retry-After is ignored #385
Description
What's wrong
GitHub. IsRateLimitResponse (BuildMonitor/Providers/GitHub.cs ~L873) correctly classifies a secondary (abuse) rate limit through its "rate limit" message, even when X-RateLimit-Remaining is far from 0. ParseRateLimitResetTime (~L857) then reads only X-RateLimit-Reset. On a secondary limit that header is the reset of the primary hourly window, often 30–60 minutes away, and is unrelated to how long GitHub wants the client to back off. The Retry-After header that GitHub sends with secondary limits (typically 60 s) is never read. GetRateLimitWaitTime() then waits min(reset − now, 10 min).
Azure DevOps. The 429 handler (BuildMonitor/Providers/AzureDevOps.cs ~L460) calls OnRateLimitExceeded() with no reset time, so the Retry-After that ADO sends is ignored too. The next request only gets the generic backoff, which can be well short of what the server asked for, so the client keeps getting throttled.
Failure scenario
The review that found this verified the GitHub case. A 403 SecondaryRateLimitExceededException with these headers:
X-RateLimit-Remaining: 4000X-RateLimit-Reset: now + 45 minRetry-After: 60
leaves the provider at Status = RateLimited with GetRateLimitWaitTime() == 00:10:00. Every GitHub request then waits 10 minutes rather than about 60 s, even though the hourly budget is nearly full. While the update pass is stuck (see the companion issue on the shared update loop), every other provider stalls with it.
Suggested fix
- GitHub: when
Retry-Afteris present, usenow + Retry-Afteras the reset time. UseX-RateLimit-Resetonly whenX-RateLimit-Remaining == 0. Otherwise, for a secondary limit with noRetry-After, back off about 60 s, as GitHub's guidance says. - Azure DevOps: read
Retry-Afterfrom theVssServiceResponseException's response (or theX-RateLimit-Reset/Retry-Afterheaders ADO returns) and pass it toOnRateLimitExceeded(...).
Acceptance criteria
- A secondary-limit 403 with
Retry-After: 60and a full primary budget yields a wait of about 60 s, not 10 min. - A primary-limit 403 (
Remaining: 0) still waits untilX-RateLimit-Reset. - An ADO 429 with
Retry-After: Nwaits about N seconds. - Unit tests cover each case through
ParseRateLimitResetTimeor its replacement.
Related: #341 and #331 cover the pacing and budget model, not how the reset time is derived.
Activity
matt-edmondson commentedon Oct 29, 2026
Triage
The GitHub half is in #388.
Retry-Afteris honoured,X-RateLimit-Resetis used only whenRemaining: 0, and otherwise the backoff is 60 s. Tests cover each acceptance case.The Azure DevOps half is not done, and the suggested fix doesn't work as written.
VssServiceResponseExceptionexposes onlyHttpStatusCodeand the message (checked by reflecting over the shippedMicrosoft.VisualStudio.Services.WebApi). There is no response object and no headers, soRetry-Aftercan't be read off the exception in the 429 catch.What it needs instead:
DelegatingHandlerpassed tonew VssConnection(uri, credentials, handlers)inAzureDevOps.CreateSession. It records theRetry-Afterof the last 429 into a sink the provider owns.MakeAzureDevOpsRequestAsyncpasses that value toOnRateLimitExceeded(...).VssHttpRetryMessageHandleralready retries 429s internally, and how the custom handlers are ordered relative to it.That can't be verified here: building a session authenticates against dev.azure.com, and
AzureDevOpsSessionTestsdocuments the same limit. The recorder itself can be unit-tested with a fake inner handler, but the wiring can't. Leaving the issue open and unassigned for that half. #388 deliberately says "Part of", so merging it won't close this issue.Generated by Claude Code