workerd triage agent hit Cloudflare API rate limit mid-migration, 200 rou

Not specified by the original author.

TL;DR: Stop the batch, write down exactly which routes already updated, and resume from that checkpoint with backoff. The Cloudflare API allows roughly 1200 requests per 5 minutes per account, and a fast migration loop burns through it, leaving the rest of the routes unmapped. Honor the Retry-After header, drop concurrency to 1-2 in flight with a short delay between calls, and verify the full route list at the end. Never re-run the batch blind - replaying completed routes burns the fresh budget on duplicates.

workerd triage agent hit Cloudflare API rate limit mid-migration, 200 routes failed to update

Steps

1. Stop the batch immediately. Build the done-list: which routes already updated, from the run log or by listing current routes. Expected: a definitive list. Never re-run without it.
2. Read the Retry-After header on the 429 response and wait at least that long. Expected: you know the real cooldown instead of guessing.
3. Resume from the checkpoint with 1-2 requests in flight and a few hundred milliseconds between calls. Expected: 200 responses resume without fresh 429s.
4. On any further 429, double the delay up to a cap, and record the checkpoint after every single success. Expected: progress survives backoffs; a second stall resumes, not restarts.
5. Verify at the end: list all routes and diff against the intended set. Expected: all 200 routes present and pointing at the right workers; empty diff.
6. Harden the next migration: chunk it (around 100 routes per chunk with a pause between), persist the checkpoint to disk after each success, and make every route update idempotent. Expected: any future stall is a resume, not a restart.

Use this when

• a bulk route migration dies partway with 429 responses
• the log shows a partial completion count and then rate-limit errors
• "200 routes failed to update" or similar partial-failure counts
• any Cloudflare API batch that outruns the request budget

Not for this skill when

• the failures are 401s - that's auth, re-authenticate instead of backing off
• specific routes fail validation - fix those routes, don't retry them harder
• it's a single route update - just retry it once after a pause
• the errors are 5xx - that's server-side, different handling

Variant phrasings

• cloudflare API 429 during bulk route migration
• migration stalled halfway with too many requests errors
• bulk route update partially completed then rate limited
• triage agent burned the API budget mid-migration

Why it happens

The API's per-account rate budget is shared across everything the account does, and a tight loop of route updates spends it in seconds. Without a checkpoint, the natural retry replays the already-completed routes first, burning the new budget on duplicates before reaching the routes that actually need work.

Edge cases

• The budget resets on roughly a 5-minute window, so a full stop of a few minutes is often the fastest recovery.
• Different endpoints draw from the same account budget. A migration running alongside other automation fails sooner.
• Log the request id from each 429. Support can confirm whether you hit the account limit or a stricter endpoint limit.
• Idempotency matters: route updates that aren't idempotent can duplicate or conflict on replay. Check before re-running.

Provenance

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

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

Thread query: workerd triage agent hit Cloudflare API rate limit mid-migration, 200 routes failed to update

TL;DR:

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: