[world-vercel] Use stream control frame for transparent reconnection#1790
Merged
VaguelySerious merged 1 commit intostablefrom Apr 17, 2026
Merged
[world-vercel] Use stream control frame for transparent reconnection#1790VaguelySerious merged 1 commit intostablefrom
VaguelySerious merged 1 commit intostablefrom
Conversation
🦋 Changeset detectedLatest commit: ee258dc The changes in this PR will be included in the next version bump. This PR includes changesets to release 18 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▲ Vercel Production (1 failed)sveltekit (1 failed):
🌍 Community Worlds (83 failed)mongodb (11 failed):
redis (7 failed):
turso (65 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. |
… with streaming hold-back buffer Re-applies #1742's reconnect feature on stable, without the arrayBuffer() rewrite that shipped in 4.2.3 (#1766) and defeated incremental streaming. - readFromStream returns the ReadableStream promptly; a hold-back buffer inside the pull loop holds only the last 13 bytes, forwarding surplus bytes as they arrive. This preserves incremental delivery for AI UIs. - On upstream close, the tail is parsed for a stream control frame (done=true → close; done=false → reconnect from nextIndex; no frame → forward tail as data for older servers). - Network errors propagate via controller.error() rather than silent close. - Caps reconnections at 50 (~100 min of streaming at 2-min server timeout). Adds a regression test that asserts data reaches the consumer before upstream close — any buffer-then-replay implementation fails it. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Peter Wielander <mittgfu@gmail.com>
d76d170 to
ee258dc
Compare
TooTallNate
approved these changes
Apr 17, 2026
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
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
Re-applies #1742's reconnect feature on `stable` — without the `arrayBuffer()` rewrite that shipped in 4.2.3 (#1766) and broke incremental streaming on Vercel (content only arrived on stream close). #1766 was reverted on `stable` (#1788, released as 4.2.4).
Root cause of the 4.2.3 regression: `await response.arrayBuffer()` inside `readFromStream` drained the upstream before returning the `ReadableStream`, so `run.getReadable()` blocked until the server closed the stream. The returned stream just replayed the already-complete buffer.
This PR restores the original hold-back buffer approach from #1742 (still in use on `main`), adapted to `stable`'s `readFromStream` signature.
What's in it
Test plan
Notes
🤖 Generated with Claude Code