mirror of
https://github.com/permissionlesstech/bitchat-android.git
synced 2026-08-15 06:56:30 +00:00
52f14cc5b5
GitHub sends X-RateLimit-Reset on every REST response, an ordinary 403 included, and it always points at the current window. Feeding it through retryAtMillis() therefore produced a non-null deadline for any 403, and the classifier accepted that as proof of a limit. A permissions failure with the quota untouched came back as RateLimited, so the caller persisted a cooldown on that route and served stale metadata until a reset window the failure had nothing to do with. Classification now looks only at signals that actually mean this request was the one refused: a spent quota, or an explicit Retry-After. Nothing real is lost, because GitHub marks a primary limit with X-RateLimit-Remaining: 0 and a secondary limit with Retry-After. The reset header keeps its job of supplying the deadline once a limit is established some other way. ApkDownloadSourceTest already claimed this contract - its name is "403 is only treated as a limit when response headers say so" - but its permissions case passed no reset header at all, which is the one input that hides the bug. Adds the case it was missing, which fails without this change, and pins the secondary-limit path so tightening the reset header cannot blind the client to a Retry-After. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>