Contributors: do not create, send, paste, or commit a GitHub token for this.
No token is needed to work on this issue, and nothing in it asks you for one.
If you ever see an issue in any project asking you to supply a credential in a
comment or a PR, that is a red flag — do not do it.
The problem
The site's GitHub poller has no rate-limit awareness at all. It discovers exhaustion by being refused, rather than by watching the budget it is spending.
Right now hushield.com runs unauthenticated, which is capped at 60 requests/hour (authenticated would be 5,000). It survives because the client sends If-None-Match and a 304 Not Modified does not count against the limit — in steady state most polls are 304s. But any burst of real changes eats the budget, and the site then shows its "showing the last known data" notice instead of current information.
Configuring a token is a separate, maintainer-only operational task and is not part of this issue. Even with one, a poller that cannot see its own budget is the actual defect — 5,000/hour is a bigger number, not a different behaviour.
What to build
In the website repo:
- Read
X-RateLimit-Remaining and X-RateLimit-Reset from every response and record them.
- Back off as the budget depletes — widen intervals instead of continuing at full rate until refused.
- Widen the baseline intervals automatically when no token is configured, since 60/hour cannot support the default schedule under churn.
- Surface remaining budget somewhere an operator can see, so the problem is visible before visitors notice.
Where to start
internal/github/client.go — the ETag handling is already here; the response headers you need are on the same responses.internal/cache/poller.go — where the per-dataset intervals live.
Design constraint
The tri-state in internal/cache/snapshot.go (Fresh / Stale / Unavailable) already means exhaustion degrades honestly rather than showing wrong data, and there are tests pinning that a failed fetch and a genuinely empty result render differently. Do not weaken that. This issue is about not reaching exhaustion in the first place.
Tests in that repo are fixture-driven and make no live API calls — please keep it that way.
The problem
The site's GitHub poller has no rate-limit awareness at all. It discovers exhaustion by being refused, rather than by watching the budget it is spending.
Right now hushield.com runs unauthenticated, which is capped at 60 requests/hour (authenticated would be 5,000). It survives because the client sends
If-None-Matchand a304 Not Modifieddoes not count against the limit — in steady state most polls are 304s. But any burst of real changes eats the budget, and the site then shows its "showing the last known data" notice instead of current information.Configuring a token is a separate, maintainer-only operational task and is not part of this issue. Even with one, a poller that cannot see its own budget is the actual defect — 5,000/hour is a bigger number, not a different behaviour.
What to build
In the website repo:
X-RateLimit-RemainingandX-RateLimit-Resetfrom every response and record them.Where to start
internal/github/client.go— the ETag handling is already here; the response headers you need are on the same responses.internal/cache/poller.go— where the per-dataset intervals live.Design constraint
The tri-state in
internal/cache/snapshot.go(Fresh/Stale/Unavailable) already means exhaustion degrades honestly rather than showing wrong data, and there are tests pinning that a failed fetch and a genuinely empty result render differently. Do not weaken that. This issue is about not reaching exhaustion in the first place.Tests in that repo are fixture-driven and make no live API calls — please keep it that way.