[core] Correct byte-stream framing capability cutoff (stable) - #2768
Merged
Conversation
The framedByteStreams capability was gated at minVersion 4.5.0, but stable 4.5.0 was published before the framing backport (#2380) merged, so 4.5.0 deployments cannot unframe framed byte streams — they silently pipe length-prefixed bytes through to user code. Gate at 4.6.0 instead, the release that actually ships framing. Additionally, replace the plain minimum-version check with a semver range: every 5.0.0-beta.x compares above any 4.x version, but betas below 5.0.0-beta.15 predate framing, so a plain >=4.6.0 check would classify them as framing-capable and corrupt byte streams written to runs or deployments from that window. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: dcc069a The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
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❌ Some tests failed Summary
❌ Failed Tests🐘 Local Postgres (1 failed)sveltekit-stable (1 failed):
🌍 Community Worlds (102 failed)redis (19 failed):
turso (83 failed):
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
❌ 🐘 Local Postgres
✅ 🪟 Windows
❌ 🌍 Community Worlds
✅ 📋 Other
❌ Some E2E test jobs failed:
Check the workflow run for details. |
pranaygp
reviewed
Jul 3, 2026
| @@ -0,0 +1,6 @@ | |||
| --- | |||
| "@workflow/core": patch | |||
| "workflow": patch | |||
Contributor
There was a problem hiding this comment.
no need for workflow in changeset
VaguelySerious
commented
Jul 3, 2026
Signed-off-by: Peter Wielander <mittgfu@gmail.com>
pranaygp
approved these changes
Jul 3, 2026
Merged
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 free
to 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.
Summary
Two fixes to the
framedByteStreamscapability gate introduced by the byte-stream framing backport (#2380, from #1853), ahead of the 4.6.0 stable release (#2426):Bump the cutoff from
4.5.0to4.6.0. Stable 4.5.0 was published ~2.5 hours before Backport #1853: [core] Add wire-level framing for byte streams #2380 merged, so published 4.5.0 has no framing code — it silently ignores theframingfield on stream refs and pipes length-prefixed bytes straight to user code. With the old cutoff, a 4.6.0 producer targeting a 4.5.0 deployment (cross-deploymentstart(), hook resume into a 4.5.0-created run) would cause silent byte-stream corruption. This resolves theTODO(release)left incapabilities.tsby Backport #1853: [core] Add wire-level framing for byte streams #2380.Replace the plain minimum-version check with a semver range (
>=4.6.0 <5.0.0-0 || >=5.0.0-beta.15, evaluated withincludePrerelease). Every5.0.0-beta.xcompares above any4.xversion, but betas below5.0.0-beta.15(published 2026-04-08 through 2026-06-11) predate framing. A plain>=4.6.0check classifies those betas as framing-capable, corrupting byte streams written from a 4.6.0 client to runs or deployments from that window (e.g. hook resumes into long-lived runs created on those betas).Misclassifying a capable version as incapable is always safe — it just falls back to the legacy raw byte format — so the range errs conservative.
Why this must land on
stable(not the release branch)The equivalent of fix 1 currently exists only as a manual commit on
changeset-release/stable(1eae02f). The changesets action regenerates that branch on every push tostable, so the next backport merge would silently drop it and #2426 would ship the corruption bug. Landing it here makes it durable.Tests
capabilities.test.ts: 4.5.0/4.5.1 and5.0.0-beta.0/5.0.0-beta.14read as raw; exact cutoffs4.6.0and5.0.0-beta.15read as framed; future prereleases above the cutoff (5.1.0-beta.0) recognized as capable.Note for
mainmain's cutoff (5.0.0-beta.15) is safe but conservative — it treats stable 4.6.x targets as raw, skipping the framing optimization. A forward-port of the range form can enable it; tracked separately.🤖 Generated with Claude Code