Readable stream from run.getReadable() silently closes after ~5 minutes while workflow continues running

[amisurec]

Description

When consuming a workflow's readable stream via run.getReadable(), the stream silently terminates after approximately 5 minutes. The workflow itself continues executing on the server, but progress updates stop coming through the readable stream on the client.

No error is thrown. No abort event fires. The streaming response simply stops receiving data at the ~5 minute mark.

Related but distinct from #964 and #943:

• Streams aren't closed automatically when runs end #964 covers streams not closing when runs end, this issue is about streams closing while runs are still active
• Bug: Workflow steps hang until 300s timeout despite completing in seconds #943 covers steps hanging until the 300s timeout, this issue is specifically about the client-side readable stream being terminated mid-workflow

Environment

• workflow: 4.0.1-beta.48
• next: 16.1.4
• Node.js: 22.x
• Deployment: Vercel (Fluid compute)
• Browser: Edge

Expected behavior

run.getReadable() should keep the stream open and deliver data for the entire duration of the workflow run. The stream should only close when the workflow actually completes or fails.

Actual behavior

After ~5 minutes (~300 seconds), the stream silently closes. The workflow still shows up as running on Vercel's side, and log observability shows API calls are still occurring — the only issue is run.getReadable() stops delivering data to the client.

Key observations:

1. No error is thrown on the client or server
2. Calling run.getReadable({ startIndex: N }) after disconnection successfully resumes the stream, proving all data is durably stored
3. Reproduces consistently for any workflow exceeding ~5 minutes of wall-clock time
4. Workflows under 5 minutes stream to completion without issue

Reproduction steps

1. Create a workflow that uses getWritable() and writes progress updates via a step function
2. The workflow should run for longer than ~5 minutes (e.g. processing items with sleep('30s') between each)
3. In the API route, call start(workflow, params) and return new Response(run.getReadable())
4. On the client, read the stream with response.body.getReader() in a while loop
5. Observe that the stream silently closes at the ~5 minute mark, even though the workflow is still running

With a workflow that takes ~10 minutes, the stream closes around the halfway point. With a workflow under ~2.5 minutes, the stream completes normally.

Workaround

Tracking the number of consumed stream entries on the client and reconnecting via a separate endpoint that calls getRun(runId) then run.getReadable({ startIndex }) works reliably. This confirms the durable log is intact and the issue is in the initial long-lived stream connection being severed.

[TooTallNate]

Your Vercel Function is timing out after the default max 5 minute runtime (you'll see a message indicating this in your deployment's logs). This is specifically why the startIndex option exists, so that your client-side can implement reconnection logic in the case of a timeout or other generic "disconnection" event.

This is exactly why we implemented WorkflowChatTransport for usage with AI SDK's useChat(). You can take a look at the code there for an example reference, or if you happen to be using useChat() already, then it's recommended that you use this transport.