Uh oh!
There was an error while loading. Please reload this page.
[ci] Fix release "Premature close" by bounding changelog GraphQL batch size - #2669
Merged
VaguelySerious merged 2 commits intoJun 26, 2026
Merged
Conversation
…h size The Release workflow's `changeset version` step has failed on the last ~10 runs with `FetchError: ... api.github.com/graphql: Premature close`. `@changesets/changelog-github` resolves each entry via `@changesets/get-github-info`, whose DataLoader is created with no `maxBatchSize`. `apply-release-plan` calls `getReleaseLine` for every changeset in one `Promise.all`, so all commits fold into a single GraphQL query. With ~300 changesets accumulated in beta pre mode, that query grows past what GitHub's GraphQL endpoint reliably serves — it returns a truncated/gzip-broken body (which node-fetch@2 surfaces as ERR_STREAM_PREMATURE_CLOSE) or a 502, aborting the whole release. The custom `.changeset/changelog.mjs` wrapper already aimed to never let a network call break the release, but only guarded its own backport lookups, not the upstream delegation that runs node-fetch. Fix: - Cap concurrent upstream calls (25) so the DataLoader batches split across several small queries GitHub can serve, preserving full PR/author attribution. Verified against the live API: 120 commits -> 5 requests of <=25 instead of one batch of 120. - Wrap the upstream delegation in try/catch with a network-free fallback line, so a transient failure on one batch degrades one entry instead of failing the release. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: fcd41ca The changes in this PR will be included in the next version bump. This PR includes changesets to release 0 packagesWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
Contributor
🧪 E2E Test Results✅ All tests passed Summary
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
|
Contributor
📊 Benchmark Results
workflow with no steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 1 step💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 10 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 25 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 50 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) Promise.all with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) Promise.all with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) Promise.all with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) Promise.race with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) Promise.race with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) Promise.race with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 10 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 25 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 50 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 10 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 25 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 50 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) Stream Benchmarks(includes TTFB metrics)workflow with stream💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) stream pipeline with 5 transform steps (1MB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) 10 parallel streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) fan-out fan-in 10 streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) SummaryFastest Framework by WorldWinner determined by most benchmark wins
Fastest World by FrameworkWinner determined by most benchmark wins
Column Definitions
Worlds:
❌ Some benchmark jobs failed:
Check the workflow run for details. |
Uh oh!
There was an error while loading. Please reload this page.
…tten summary verbatim, leaking injected `pr:`/`commit:` directive lines into the changelog so the entry title becomes literally `pr: #N`.
This commit fixes the issue reported at .changeset/changelog.mjs:368
## Bug
`maybeRewriteChangesetForBackport` prepends directive lines to a backport changeset's summary:
```js
const rewrittenSummary =
`pr: #${originalPRNumber}\n` +
`commit: ${changeset.commit}\n` +
summary;
return { ...changeset, summary: rewrittenSummary };
```
The upstream `@changesets/changelog-github` `getReleaseLine` consumes those directives and **strips them** from the summary (via `.replace(/^\s*(?:pr|pull|pull\s+request):.../im, ...)`, `commit:`, `author:` etc.) before splitting into `firstLine`/`futureLines` and rendering. So in the normal path the directives never appear in the output — that's the whole point of injecting them.
The offline fallback, however, does **not** strip them:
```js
function offlineReleaseLine(changeset, options) {
const [firstLine, ...futureLines] = (changeset.summary ?? '')
.split('\n')
.map((l) => l.trimEnd());
...
}
```
It just splits on `\n` and renders verbatim.
### Concrete trigger
A backport changeset where:
1. `maybeRewriteChangesetForBackport` **succeeds** (network up, PR resolved, directives injected → `rewritten.summary` starts with `pr: #N\ncommit: <sha>\n`), and
2. the subsequent `limitUpstream(() => upstream.getReleaseLine(rewritten, ...))` **throws** — exactly the flaky/oversized GraphQL batch scenario this fallback was added for.
The catch block then ran `offlineReleaseLine(rewritten, options)`, producing:
```
- [`abc1234`](...) - pr: #123
commit: abc1234...
<real first line>
```
The entry title becomes literally `pr: #123` and `commit: …` leaks as body text.
## Fix
Pass the **original** `changeset` to `offlineReleaseLine` instead of `rewritten`. The backport rewrite only mutates `summary`; `changeset.commit` is untouched, so the offline commit link is identical, while the original summary has no injected directives. The offline path already drops PR/author attribution it can't resolve, so using the un-rewritten summary is exactly correct.
The dependency-line path (`offlineDependencyReleaseLine`) is unaffected since no directive injection happens there.
Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
Co-authored-by: VaguelySerious <mittgfu@gmail.com>
pranaygp
left a comment
Contributor
There was a problem hiding this comment.
Reviewed the diff and verified the core mechanism end to end against the real file (stubbed upstream, Node 22.18, require()-able ESM confirmed):
- Limiter works as claimed: 120
getReleaseLinecalls → max 25 concurrent → ~5 DataLoader batches of ≤25, order preserved. Sinceget-github-info's DataLoader is a module-level singleton built with nomaxBatchSize(confirmed inget-github-info@0.7.0src) and eachgetReleaseLinefires exactly one.load(), gating concurrency at 25 genuinely bounds the per-batch query size while preserving full PR/author attribution. Good, well-reasoned fix. - Offline
getReleaseLinemirrors the upstream template exactly (changelog-github@0.5.2):`\n\n-${prefix ? ` ${prefix} -` : ''} ${firstLine}...`, dropping only the pull/Thanks attribution. The 2nd-commit fix (feed the original changeset, notrewritten) is correct and I confirmed it no longer leakspr:/commit:directives. - Offline dependency line is lossless — dep lines only ever render commit links, which you reconstruct from the SHA, so that path loses nothing even when it falls back.
LGTM to ship — it unblocks the release. A few non-blocking notes inline (one substantive: the dependency-rollup path isn't actually batch-bounded by the limiter and is carried entirely by the fallback).
| // truncated/gzip-broken body (which `node-fetch@2` surfaces as | ||
| // `ERR_STREAM_PREMATURE_CLOSE`) or a 502, aborting the whole release. | ||
| // 6. Wraps the upstream delegation in a try/catch with a network-free | ||
| // fallback line, so a transient failure on one batch degrades a single |
Contributor
There was a problem hiding this comment.
Minor wording: "degrades a single entry" undersells it. When an oversized getReleaseLine batch fails, every .load() sharing that one fetch rejects together, so a whole batch (~UPSTREAM_CONCURRENCY, up to 25 entries) drops to the offline line at once — not one. The important half ("instead of failing the release") still holds; just the count is off.
| options, | ||
| ); | ||
| try { | ||
| return await limitUpstream(() => |
Contributor
There was a problem hiding this comment.
The concurrency gate bounds the getReleaseLine batch nicely, but it does not bound this path's batch. apply-release-plan's getChangelogEntry calls getDependencyReleaseLine once per release with relevantChangesets (every changeset that bumped that package's deps), and upstream fans out to one getInfo() per changeset inside a single internal Promise.all — so all of those .load()s land in one DataLoader batch within this one limiter slot. A package whose deps were bumped by hundreds of changesets (e.g. the many packages depending on @workflow/core) therefore still produces one oversized query here, exactly the shape this PR is fixing.
In practice the release stays safe: that query throws → catch → offlineDependencyReleaseLine, which is lossless for dependency lines (they only render commit links). So no functional gap. But point 5's rationale — "splits its lookups across several small GraphQL queries" — only really applies to getReleaseLine; this path is carried by the fallback, not by batch-splitting. Worth a word in the comments so the next reader doesn't assume both paths are bounded (or, if you want it truly bounded, gate the per-getInfo fan-out rather than the outer call).
| // the changelog (the entry title would become literally `pr: #N`). The | ||
| // rewrite only touches `summary`; `changeset.commit` is unchanged, so the | ||
| // offline commit link is identical either way. | ||
| return offlineReleaseLine(changeset, options); |
Contributor
There was a problem hiding this comment.
Good fix on the backport-rewrite leak. One residual of the same class: if a changeset's summary manually contains a pr:/commit:/author: directive, maybeRewriteChangesetForBackport returns it unchanged (the guard at L309), upstream would strip it before rendering — but the offline path renders it verbatim, so the entry title becomes literally pr: #123 (confirmed locally). Much rarer than the backport case (needs a hand-written directive and an upstream failure), so not a blocker. If you want the offline path to fully match upstream, strip the leading directive lines here the same way upstream's .replace(/^\s*(?:pr|pull|...|author|user):/im, '') chain does.
| : ` \`${short}\``; | ||
| } | ||
| function offlineReleaseLine(changeset, options) { |
Contributor
There was a problem hiding this comment.
Optional: these offline helpers + the limiter are pure and easy to unit-test, and the directive leak already regressed once (needed a follow-up commit), which is a good signal this file is edit-fragile. A tiny test — force upstream to throw and assert the offline line keeps the commit link + a clean title, plus assert 120 calls never exceed 25 concurrent — would be cheap regression insurance. No test runner is wired for .changeset/ today, so low priority, but worth considering.
pranaygp
approved these changes
Jun 26, 2026
Uh oh!
There was an error while loading. Please reload this page.
github-actionsBot
added a commit
that referenced
this pull request
Jun 26, 2026
…h size (#2669) Signed-off-by: Peter Wielander <mittgfu@gmail.com>
Contributor
Backport PR opened against |
pranaygp added a commit
that referenced
this pull request
Jun 26, 2026
…edrive * origin/main: (90 commits) [ai] Fix "missing text part" stream crash by repairing UI message framing (#2537) [ci] Fix release "Premature close" by bounding changelog GraphQL batch size (#2669) [ai] Drop orphan UI chunks after negative-index reconnect (#2082) Fix trace detail panel Input/Output flicker (selection-driven state machine) (#2637) [world-local] Scope untagged startup recovery to untagged runs (#2667) fix(world-postgres): defer loopback worker startup (#2657) docs: deprecate DurableAgent and WorkflowChatTransport, point to AI SDK WorkflowAgent (#2616) [web] Fix HTTP/2 in bundled server build so observability reads work (#2632) [core] Fix turbo-mode step-body writes racing run_started (#2629) fix(world-postgres): rename setup command (#2644) chore: ignore workflow swc caches (#2640) fix(ai): ignore intentional stream aborts (#2635) fix(nitro): reload steps during Vite HMR (#2572) [world] Make @workflow/world own its Zod dependency (#2622) feat(web-shared): extend cn with custom tailwind-merge class groups (#2619) [world-vercel] Enable HTTP/2 for the events API and stream writes (#2573) Remove shadow from off-screen marker indicator button (#2614) Fix discovery of dotted JS workflow imports (#2594) Version Packages (beta) (#2597) Thread occurredAt into web-shared entities (#2608) ... # Conflicts: # packages/core/src/runtime/step-executor.ts # packages/world-vercel/src/http-client.ts
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The Release workflow's
pnpm ci:version(changeset version) step has failed on the last ~10 runs (e.g. run 28264162169) with:Root cause
@changesets/changelog-githubresolves each changelog entry via@changesets/get-github-info, whoseDataLoaderis constructed with nomaxBatchSize.@changesets/apply-release-plancallsgetReleaseLinefor every changeset inside onePromise.all, so all commits fold into a single GraphQL query.We currently have ~300 changesets accumulated (beta pre mode, not yet flushed). That one query grows past what GitHub's GraphQL endpoint will reliably serve. Reproduced against the live API with the exact query shape on Node 24 + node-fetch@2.7.0:
invalid json "<html>…"GitHub returns a truncated/gzip-broken body — which
node-fetch@2surfaces asERR_STREAM_PREMATURE_CLOSE— or a 502, aborting the whole release. It's deterministic now because the backlog is reliably past the threshold, and it only grows.The custom
.changeset/changelog.mjswrapper already intends to "never want a flaky network call to breakpnpm changeset version", but only guarded its own backport lookups — not theupstream.getReleaseLinedelegation that runs node-fetch.Fix
get-github-info.load()calls per tick, which bounds the DataLoader batch — so the work splits into several small queries GitHub serves reliably, preserving full PR/author attribution.Validation (empirical, against the live GitHub API)
p-limit(25)→ 5 requests, max batch 25.[\sha`](…)commit link +Thanks @…` attribution.ERR_STREAM_PREMATURE_CLOSE: no throw, well-formed offline line with commit link + multi-line summary.🤖 Generated with Claude Code