[tmlayton]

Fixes #145. Refs #143.

Why United States stopped updating on 2026-08-24

One United States user's data is now too costly for GitHub to return. Every request for the page that holds them fails, either with RESOURCE_LIMITS_EXCEEDED on contributionsCollection or with a timeout body that is not JSON. SearchUsers retries the same page every time, so all ten retries hit the same user and log.Fatalln("Too many errors received. Quitting.") fails the whole location. No code on master changed since March, so this is data-driven: other countries do not hold that user.

Evidence from upstream daily update runs that picked united_states:

Run	What the log shows
38896983332	3 non-JSON responses, then 6 identical RESOURCE_LIMITS_EXCEEDED on the same page
39063640920	1 missing data, 2 non-JSON, then 6 identical RESOURCE_LIMITS_EXCEEDED
39792877820	9 non-JSON responses in a row

Change (github/github.go only, plus tests)

• A failing page is retried in place (same cursor) one user at a time, instead of restarting the search window.
• When a single user still fails 3 times and a light query for them (login, followers) succeeds, that user is skipped and logged as Skipping <login>: …; the search continues after them. If the light query also fails, nothing is skipped (so rate limits or outages never drop users).
• The retry limit counts consecutive errors. More than 10 skipped users still fails the run, so a broken search cannot publish an empty page.
• Windows are paged by results consumed, and the cursor advances past every edge, so a page-size change cannot end a 1000-result window early.
• Dropped totalPullRequestContributions: nothing reads it, and it is the field named in the RESOURCE_LIMITS_EXCEEDED errors.

Tests

github/github_test.go adds a fake search API (no network) that honours followers:<N, first/after and the 1000-result cap:

• every user returned on a clean search;
• a user whose data never loads is skipped (first, middle and last position), with everyone else kept;
• a skip across the 1000-result cap keeps every later user;
• errors scattered over a long search no longer add up to a failure, and nobody is skipped for them.

With the skip turned off, the skip tests fail with the production message Too many errors received. Quitting.. go fmt, go vet ./..., go build ./..., go test ./... pass; golint reports no new warnings.

United States verify run

Ran this change through my fork's daily update workflow for united_states only (run 40580390211, green). It pushed 4c6f9ea63, the first United States refresh since 2026-08-24:

	Live (2026-08-24)	This run (2026-10-27)
generated	2026-08-24T03:48:50Z	2026-10-27T21:07:42Z
min_followers_required	1517	1550
total_user_count	1,903,738	1,966,879

Top of the new list: 1. jverkoey 159,050 · 2. steipete 102,696 · 3. lalalune 49,065 · 4. rgbkrk 28,775 · 5. vincentkoc 27,760.

What the log shows:

• Two users were skipped: colinhacks and punkpeye. Each failed four times in a row with RESOURCE_LIMITS_EXCEEDED on contributionsCollection, also at page size 1, so they are the users who have blocked the location. They are left out of this run's list; that is the trade-off of this fix.
• With totalPullRequestContributions gone, the error now names restrictedContributionsCount. So dropping the unused field does not fix this on its own; the skip does.
• 29 retried errors in total, mostly non-JSON (<) timeout bodies. All recovered; none caused a skip.

(The fork-only branch verify-145 adds a dispatch input to run one location, permissions: contents: write because a fork's default token is read-only, and prints the generator log. None of that is in this PR.)

Relation to #146 and #148

Both target this issue. #146 halves the page size on RESOURCE_LIMITS_EXCEEDED and resets the retry count, which cannot get past a user who fails at page size 1 or with a non-JSON timeout (most of the logs above). #148 skips such a user, like this PR, in a larger rewrite (github.go +262/−129). This PR is a smaller version of that skip (github.go +141/−91, plus tests). It adds a real United States run as evidence (above). Happy to close this in favour of #148 if you prefer that one.

[tmlayton]

@ashkulz