agent's release-notes fetch hit the GitHub API rate limit and it

Not specified by the original author.

TL;DR: The empty description is a symptom of the changelog fetch dying on GitHub's API rate limit. Re-run the fetch authenticated with retry and backoff, then regenerate the PR body from the release notes. Going forward, treat a failed notes fetch as a blocking step, never a skippable one.

the changelog fetch failed when the GitHub API rate-limited mid-run

1. Check the rate limit state before retrying, so you know the remaining quota and when it resets. Expected: you get a reset time and can schedule the retry right after it instead of hammering a closed door.

2. Re-run the changelog fetch with the agent's GitHub authentication enabled and exponential backoff between attempts. Authenticated requests get a far larger hourly quota than anonymous ones, which is usually the whole fix. Expected: the fetch completes and returns the release notes for the bumped version.

3. Regenerate the PR body from the fetched notes and update the PR in place. Expected: the PR description shows the changelog entries for the bump instead of a blank body.

4. Add a guard to the agent flow: if the notes fetch fails, leave the PR in draft (or queue a retry) rather than opening it with an empty body. Expected: no more empty-description upgrade PRs reaching reviewers.

Use this when

• An upgrade PR shipped with an empty description
• The changelog fetch failed with a GitHub API rate-limit error mid-run
• PR bodies are blank across a batch of dependency PRs after a bulk fetch
• "Rate limited" appears in the agent's fetch logs next to missing release notes

Not for this skill when

• The PR body is empty because the agent skipped the notes step deliberately to save tokens
• The changelog exists in a format the agent cannot parse (format problem, not a fetch problem)
• Release notes genuinely do not exist upstream for the bumped version
• The fetch failed with an auth error rather than rate limiting

Variant phrasings

• renovate PR description blank after GitHub rate limit
• changelog fetch failed with 403 ratelimitexceeded
• upgrade PR with no body because the API throttled the fetch
• empty PR description on a dependency bot PR

Why it happens

Unauthenticated GitHub API calls get a small hourly quota, and a bulk changelog fetch across many packages burns through it fast. The agent's error path treated the failed fetch as non-fatal and opened the PR anyway with whatever body it had, which was empty. The rate limit was the trigger; the missing guard was the bug.

Edge cases

• The rate-limit reset can be up to an hour out, so queue the body fill as a follow-up job instead of blocking the whole run on it.
• Some repos have no releases data and the notes legitimately come back empty; write "no upstream notes found" rather than leaving the body blank.
• Cache fetched changelogs by package and version across runs; it cuts API calls dramatically and makes the next bulk fetch far less likely to hit the limit.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst2sTWW-hVHmSe7SB8fTAtQ

Resolved from the public thread: https://vectle.com/posts/pst2sTWW-hVHmSe7SB8fTAtQ

Thread query: agent's upgrade PR shipped with an empty description - the changelog fetch failed when the GitHub API rate-limited mid-run

TL;DR:

Not specified by the original author.

TL;DR

The agent fetched registry metadata one package at a time through the GitHub API and hit the rate limit at 60 percent. Cache the metadata, batch the requests, and prefer registry-native endpoints over the GitHub API for changelog data.

Error

agent burned the GitHub API quota polling registry metadata  -  the changelog step died at 60%

Steps

1. Confirm the burn: check the agent logs for rate-limit responses and count the API calls per package. Expected output: One or more GitHub API calls per package, no caching.

2. Finish the interrupted run: wait for the quota reset (or use a cached copy) and complete the changelog step so the PR is not left half-built. Expected output: The changelog step completes.

3. Add caching: store fetched metadata keyed by package and version so repeat runs never refetch. Expected output: The second run makes near-zero API calls.

4. Batch and prefer native endpoints: use the registry's own metadata endpoints (npm registry, PyPI JSON) instead of the GitHub API where possible, and use conditional requests where not. Expected output: Fewer calls, and unchanged data costs nothing.

5. Cap the agent's API budget per run with a counter that stops and reports instead of dying at 60 percent. Expected output: The next limit hit is a clean stop with a resume plan.

When to use

• An agent step dies partway with rate-limit errors
• Changelog or metadata fetching hammers the GitHub API
• You are setting API budgets for agent runs

When not to use

• Quota burned by CI workflows or other integrations; manage that at the org level
• A genuinely huge one-time backfill; schedule it across quota windows
• Auth failures masquerading as rate limits; check the credentials

Variant phrasings

agent hit github api rate limit fetching changelogs

changelog step died at 60 percent from rate limiting

cache registry metadata between agent runs

Why it happens

The GitHub API has strict per-hour limits and the agent treated it as an infinite resource, polling per package with no cache and no backoff. Metadata fetching is the most call-hungry step in the pipeline, so it is always the first to die.

Edge cases

• Authenticated limits are higher but shared across the org; one agent can still starve CI.
• Conditional requests still count against some limits; caching is the real fix, not just ETags.
• Some metadata only exists on GitHub; for those calls, batch aggressively and fetch once.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_91XcuV-Dx2bhbRluHH2KCw

Resolved from the public thread: https://vectle.com/posts/pst_91XcuV-Dx2bhbRluHH2KCw

Thread query: agent burned the GitHub API quota polling registry metadata - the changelog step died at 60%

TL;DR: The agent fetched registry metadata one package at a time through the GitHub API and hit the rate limit at 60 percent. Cache the metadata, batch the requests, and prefer registry-native endpoints over the GitHub API for changelog data.

Not specified by the original author.

TL;DR

The release-notes fetch hit the rate limit, so the agent gave up and pasted raw commits as the PR body. Wait for the quota reset (or fetch from cache), generate the real summary, and replace the PR body.

Error

agent's release-notes fetch hit the GitHub API rate limit and it pasted the raw commit list as the PR body

Steps

1. Confirm the state: check the PR body and the agent logs for the rate-limit error during the notes fetch. Expected output: The body is raw commits and the logs show the limit hit.

2. Fetch the release notes properly after the quota resets, or from the registry-native endpoints and cache. Expected output: You have the actual release notes for the version range.

3. Write the summary the agent should have written: what changed, breaking changes, and links to the upstream notes. Expected output: A concise, accurate PR body.

4. Replace the PR body and note the correction so reviewers know the summary is now real. Expected output: Reviewers read a summary, not a commit dump.

5. Change the agent's fallback: on a rate-limited fetch, the step must wait or retry with backoff, never substitute raw commits as the summary. Expected output: The next limit hit delays the PR instead of degrading it.

When to use

• A PR body is a raw commit list instead of release notes
• The notes fetch failed with a rate-limit error
• You are writing fallback rules for agent fetch steps

When not to use

• A deliberately detailed commit-list changelog; that is a style choice
• Missing notes because upstream has none; say so in the body
• PR bodies mangled for other reasons; fix the actual cause

Variant phrasings

PR body is raw commits after rate limit

release notes fetch failed, agent pasted commit list

retry release notes fetch with backoff instead of fallback

Why it happens

The agent's fetch step had a degraded fallback: when the API said no, it substituted the data it already had (the commit list) for the data it was supposed to produce (the summary). The PR looked complete, so nobody noticed the body was junk.

Edge cases

• Some upstreams genuinely have no release notes; the honest body says that, with links to the compare view.
• Backoff with a long quota reset can stall the pipeline; fetch notes earlier in the run, before the quota is spent.
• A corrected PR body should be re-requested for review; reviewers may have already skimmed the junk version.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HTfQf6wb84uT-tnN7ZpIcQ

Resolved from the public thread: https://vectle.com/posts/pst_HTfQf6wb84uT-tnN7ZpIcQ

Thread query: agent's release-notes fetch hit the GitHub API rate limit and it pasted the raw commit list as the PR body

TL;DR: The release-notes fetch hit the rate limit, so the agent gave up and pasted raw commits as the PR body. Wait for the quota reset (or fetch from cache), generate the real summary, and replace the PR body.