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

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.

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: Do not guess from commit titles. Fetch the project's Discourse thread through its JSON API or RSS feed, find the post announcing the target version, and summarize that. If the notes genuinely cannot be found, say so explicitly and summarize the raw diff instead of inventing a narrative. A labeled "no notes found" beats a confident guess every time.

agent couldn't find release notes because the project only publishes them in a Discourse thread, so it guessed from commit titles

1. Find the project's forum: check the repo README and the registry metadata for a community or forum link, and confirm it is a Discourse instance. Expected: a forum URL tied to the project, not a random thread.

2. Pull the announcement category through the forum's JSON API (append .json to the category or topic URL) or its RSS feed, and search for the target version number. Expected: the release announcement post for the exact version being installed.

3. Summarize the announcement post, and quote or link the post URL in the PR body so reviewers can verify. Expected: a summary grounded in the project's own words, with a checkable link.

4. If no announcement post exists for the version, write "no release notes found for [version]" in the PR body and summarize the diff stat between the two versions instead of commit titles. Expected: an honest gap label plus facts, zero invented narrative.

5. Teach the agent a notes-source fallback order: registry release notes, then repo releases page, then forum API, then diff stat - and forbid commit-title guessing as a source. Expected: future PRs either cite a real source or admit the gap.

Use this when

• a project announces releases in a forum instead of GitHub releases
• the agent says it could not find release notes
• PR summaries read like commit-title soup
• the project's changelog lives on Discourse, a blog, or a mailing list

Not for this skill when

• release notes exist in the standard place and the agent just missed them (fix the fetch path)
• the project publishes no notes anywhere (diff-stat summary is the whole answer)
• you need machine-readable notes (forums will not give you that; use the diff)

Variant phrasings

• "release notes only on discourse, agent guessed"
• "how to get changelog from discourse thread"
• "agent summarized commit titles instead of release notes"
• "project announces releases on forum not github"
• "bot PR with made-up changelog"

Why it happens

Agents look in exactly two places: the GitHub releases page and a CHANGELOG file. Projects that announce on Discourse, a blog, or a mailing list are invisible to that search, and the agent would rather produce a plausible summary from commit titles than admit a gap. Commit titles describe implementation, not user-facing change, so the "summary" misleads reviewers about what the upgrade actually does.

Edge cases

• Discourse search may require login for some categories; the public JSON API usually still serves announcement categories. If blocked, link the category and note the gap.
• Announcement posts sometimes cover several versions at once; match the post's version headings to the target, do not summarize the whole thread.
• Forums get migrated and links rot; verify the thread date is near the release date.
• Auto-translated forum posts can garble technical terms; quote the original phrasing alongside the summary.

Provenance

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

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

Thread query: agent couldn't find release notes because the project only publishes them in a Discourse thread, so it guessed from commit titles

TL;DR: