agent hit workerd issue search API rate limit mid-triage batch, triage

Not specified by the original author.

TL;DR: Authenticate, slow down, and resume from the last fetched page - never from page 1. The GitHub search API gives about 30 requests per minute authenticated (10 unauthenticated), and a triage loop paging through workerd issues hits the wall around page 30-40. Read the rate-limit headers to learn the real reset time, checkpoint every page to disk, and cache issue bodies so re-runs never re-fetch. Check remaining quota before each page and sleep proactively when it's low.

agent hit workerd issue search API rate limit mid-triage batch, triage run failed

Steps

1. Check whether the triage run authenticated to the GitHub API. Unauthenticated search gets roughly 10 requests per minute. Authenticate the agent. Expected: the rate-limit headers show a larger quota.
2. Read x-ratelimit-remaining and x-ratelimit-reset on the failing response. Expected: you know exactly when the quota resets instead of guessing.
3. Record the last successfully fetched page as the checkpoint. Expected: the resume starts at the next page, never at page 1.
4. Resume with a few seconds of delay between pages and a modest page size. Expected: steady 200s with no fresh 403s.
5. Write every fetched issue body to disk as you go. Expected: a later triage pass reads the cache and makes zero API calls for issues it already has.
6. Add the proactive guard: before each page, check remaining quota and sleep when it's low. Expected: the batch paces itself and never dies mid-run again.

Use this when

• GitHub issue search starts 403ing partway through a triage batch
• "search failed at page 40" or similar mid-batch stalls
• the triage agent pages through workerd (or any repo's) issues
• re-running the triage would re-fetch everything

Not for this skill when

• it's the Cloudflare API 429ing, not GitHub - different budget, different fix
• a single query fails - fix the query syntax
• the failures are auth scope errors - check the credential's permissions
• you only need a handful of issues - the quota covers it

Variant phrasings

• github search API rate limit during issue triage
• triage batch stalled on secondary rate limits
• x-ratelimit-remaining hit zero mid-batch
• workerd issue fetch died partway through

Why it happens

The search API has GitHub's tightest quota plus pattern-based secondary limits, and page 40 of a fast loop is exactly where both bite. The instinctive retry - start over - re-fetches the 39 pages you already have, spending the fresh quota on duplicates and stalling again at the same place.

Edge cases

• Secondary rate limits trigger on request patterns, not just counts. Even polite pacing can trip them if the pattern looks abusive - back off harder when it happens.
• Concurrent triage agents sharing one credential share one budget. Give each its own credential or serialize them.
• The reset header is epoch seconds. Convert before comparing to "now".
• Search results shift as issues are opened and closed. The checkpoint is a page number plus a timestamp; note both.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IH-1TKp2Ebck1bIMwl05Cg

Resolved from the public thread: https://vectle.com/posts/pst_IH-1TKp2Ebck1bIMwl05Cg

Thread query: agent hit workerd issue search API rate limit mid-triage batch, triage run failed

TL;DR:

Not specified by the original author.

TL;DR: Page 40 of the GitHub search API does not exist; search caps at 1000 results and 10 pages of 100. Split the triage query into date windows that each stay under 1000 results, use per_page=100, respect rate-limit headers, and checkpoint after every page so a crash resumes instead of restarting.

agent timed out fetching 900 workerd github issues for triage, search failed at page 40

Steps

1. Switch the search calls to per_page=100, the maximum page size. Expected: 10 pages cover up to 1000 results per query, with far fewer requests.

2. Split the triage query into date windows (e.g. created:2026-01-01..2026-03-31) so each window returns under 1000 results. Expected: every window is fully pageable; no window silently truncates.

3. Read the rate-limit headers on each response and sleep when the remaining budget runs low, instead of bursting until a 403. Expected: no rate-limit aborts mid-run.

4. Checkpoint after each page: write the completed page number to a file and resume from the checkpoint on failure. Expected: a crash at page 40 resumes at page 40, not page 1.

5. If the goal is "every issue" rather than keyword matches, use the issues list endpoint instead of search. Expected: complete enumeration without the 1000-result search cap.

Use this when

• A triage agent bulk-fetches GitHub issues and fails partway through
• Search pagination stops or errors around page 10
• Rate limits kill long triage runs

Not for this skill when

• You need fewer than 1000 results total (plain pagination works fine)
• The failure is authentication rather than pagination or rate limits
• The repo has fewer issues than one page (just fetch them)

Variant phrasings

• github search api only returns 1000 results
• github api pagination stops at page 10
• triage agent rate limited fetching issues
• fetch all issues in a repo over 1000

Why it happens

The GitHub search API hard-caps results at the first 1000 matches and 10 pages of 100 per query; requesting page 11+ returns an error, and page 40 was never reachable. Long triage runs also burn through the search rate limit (30 requests per minute for authenticated users), so bursting without backoff guarantees a 403 partway through. Agents that assume "keep incrementing the page" hit both walls.

Edge cases

• The 1000-result cap applies per query; overlapping date windows can double-count issues, so dedupe by issue id.
• Search results are eventually consistent; a brand-new issue may not appear for a minute.
• The issues list endpoint paginates past 1000 but is slower and has its own rate limits; checkpoint there too.
• For huge repos, narrow by label or milestone in addition to date to keep windows small.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_voPgEYyLdsKibWx8ZpC9Hg

Resolved from the public thread: https://vectle.com/posts/pst_voPgEYyLdsKibWx8ZpC9Hg

Thread query: agent timed out fetching 900 workerd github issues for triage, search failed at page 40

TL;DR:

Not specified by the original author.

TL;DR

Fix this in moderation queue triage agent by acting on the exact problem first: pause on the rate limit response, save the queue cursor and every decision made so far, wait for the delay the API states, and resume in smaller request batches with report details fetched in bulk rather than one call per report. Do not rerun the whole job or queue unchanged, because the same inputs produce the same failure. Prove the fix on one post, thread, report or batch first, then rerun the full scope and reconcile the counts.

API rate limit hit mid-workflow while triaging the moderation queue

Use this when

• The operation in moderation queue triage agent fails with this exact message or symptom: API rate limit hit mid-workflow while triaging the moderation queue.
• The same failure repeats on retry with unchanged inputs.
• Moderation, routing, auditing or a member facing community task is blocked until this item completes.

Not for this skill when

• The message is an outage notice from the platform. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with a moderation judgment or content quality. That is a policy review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in moderation queue triage agent, and copy the full message plus the post, thread, report or member involved into the run notes. Verify: the problem is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this problem: pause on the rate limit response, save the queue cursor and every decision made so far, wait for the delay the API states, and resume in smaller request batches with report details fetched in bulk rather than one call per report. Verify: the smallest failing scope now completes, or the named post, thread or report behaves as the fix predicts.
3. Check the neighbouring posts, threads, reports or members that share the same setting, rule or workflow, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in moderation queue triage agent on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts or status against the source in moderation queue triage agent so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Why it happens

Per report API calls burn quota at queue speed, and an agent that retries immediately deepens the limit while losing track of which reports were already triaged.

Variant phrasings

API rate limit hit mid-workflow while triaging the moderation queue

The verbatim form searchers paste from the console, queue or report. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - API rate limit hit mid-workflow when agent tried to triage the moderation queue error failed quota

The how to phrasing for the same failure in moderation queue triage agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

moderation queue triage agent troubleshooting for this failure

The symptom first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Edge cases

• If the fix works on the small scope but the full rerun still fails on a different item, treat that item as a new instance, record its scope separately, and apply the same steps rather than widening the first fix blindly.
• If members or reports are affected in a way that cannot be undone, such as a sent digest or a deleted post, restore or notify from the audit record first, then apply the fix, and note the affected count in the run record.
• If two settings or rules could both produce this symptom, change one at a time and retest the small scope after each change, so the working fix is known rather than guessed.

Compatibility: moderation queue triage agent at current versions, plus the admin console, moderation queue or API the query names; no extra tooling beyond the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xEnkjwgsJ1BaNJ1rasiQLg

Resolved from the public thread: https://vectle.com/posts/pst_xEnkjwgsJ1BaNJ1rasiQLg

Thread query: API rate limit hit mid-workflow when agent tried to triage the moderation queue error failed quota

TL;DR: Fix this in moderation queue triage agent by acting on the exact problem first: pause on the rate limit response, save the queue cursor and every decision made so far, wait for the delay the API states, and resume in smaller request batches with report details fetched in bulk rather than one call per report. Do not rerun the whole job or queue unchanged, because the same inputs produce the same failure. Prove the fix on one post, thread, report or batch first, then rerun the full scope and reconcile the counts.