[tiagolpadua]

Users with more than 200 accessible repositories couldn't find some of them in Settings. The list now loads every repository; the 200 cap only applies to the fallback polling used when nothing is selected.

[pch]

🤖 This review comment was written by Claude (AI assistant) on behalf of the maintainer.

Thanks for the PR! The motivation makes sense, but we'd rather not merge it as-is because of how it interacts with GitHub's API rate limits.

The concern: rate limits

Polling makes one request per selected repo on every refresh (fetchRecentRuns, 4 concurrent). The 200 cap on the list was also, implicitly, a cap on how many repos the "All" button could select. With this change, "All" can select every accessible repo:

Selected repos	Interval	Requests / hour
200 (today's max)	15s	~48,000
2,000	15s	~480,000
2,000	5 min	~24,000

GitHub's budget for user-to-server tokens is ~5,000 requests/hour, so a user who picks "All" with a large account gets rateLimited almost immediately and stays there. The current select-all warning only says it "will slow things down" and doesn't mention the count or the rate limit.

Two smaller side effects:

• Loading the list itself is now unbounded: pages are fetched one after another (100 per request), so 5,000 repos means ~50 requests in a row from the same hourly budget, with a spinner and no progress. fetchAvailableRepos uses try?, so one failed or rate-limited page discards everything fetched so far.
• Fallback polling still takes the first 200 in API order (not alphabetical, since the cap is applied before sorting), but the "Only the first 200…" hint is gone, so the cap is now invisible.

A possible alternative

Keep 200 as the default, but let users opt out with a setting, e.g. a "Repository list limit" option: 200 (default) / No limit. That way:

• Large accounts that need it can list everything, knowingly.
• The capped notice stays (and could point to the setting).
• The select-all warning should still be strengthened when the selection is large: show the number of repos and the estimated requests/hour for the current polling interval, or refuse past a hard ceiling.

Happy to look at a revised version along those lines.

[pch]

🤖 This comment was written by Claude (AI assistant) on behalf of the maintainer.

Reopening. Closing this was a mistake on my part, sorry about that.

My earlier review mixed up two different things: which repos are listed in Settings and which are polled. This PR only changes the list. Polling still happens only for the repos a user selects, and the fallback (nothing selected) is still capped at 200 via maxFallbackRepositories. Users with more than 200 repos can now find and select the ones they need, which is the bug being fixed.

Corrections to the earlier comment:

• The rate-limit numbers were overstated. Polling already uses conditional requests (If-None-Match / ETag), and GitHub doesn't count 304 responses against the rate limit.
• The 200 cap never really protected the budget anyway: 200 selected repos at a short interval is already over the hourly limit, so the cap wasn't acting as a safeguard.
• The only real new risk is the "All" button selecting a very large set. That's a select-all UX issue and can be handled separately (e.g. showing the count / estimated request rate in the warning), not by hiding repos from the list.

Two minor points remain, but neither blocks this PR and both can be follow-ups:

• fetchAvailableRepos uses try?, so one failed page discards the whole list. This already happens today.
• With the "Only the first 200…" hint gone, the fallback cap isn't visible anywhere in the UI.

Thanks for the contribution, and apologies for the noise.