Bug: Workflow steps hang until 300s timeout despite completing in seconds

[oabudayyeh]

The Problem

I'm building an agent using Vercel Workflow where each turn of the agent is a separate workflow step. The steps themselves execute quickly—typically 0.4-2 seconds—but the serverless functions hosting them don't terminate. Instead, they hang for the full 300 seconds before timing out.

The strange part is that the workflow actually works correctly. Each step completes its task, returns its state, and the workflow continues to the next step without issue. But in the background, the function that ran that step is still alive, doing nothing, just waiting to time out. This results in ~295 seconds of wasted compute per step.

Environment

• Package: workflow version 4.0.1-beta.50
• Platform: Vercel Pro plan
• Runtime: Node.js

What I'm Seeing

Here's a snippet from my logs showing the pattern—the step finishes in under a second, but timeout errors pile up from functions that have been hanging:

Feb 04 17:41:07.26 - [CleanupSandbox] ✅ Sandbox stopped successfully
Feb 04 17:41:06.21 - [Workflow] Turn 39: 0.41s
Feb 04 17:41:03.07 - Vercel Runtime Timeout Error: Task timed out after 300 seconds
Feb 04 17:41:01.05 - Vercel Runtime Timeout Error: Task timed out after 300 seconds
Feb 04 17:40:55.94 - Vercel Runtime Timeout Error: Task timed out after 300 seconds
... (dozens more 300s timeout errors, all within seconds of each other)

Turn 39 completed in 0.41 seconds. But the functions from earlier turns are still hanging around, finally timing out 300 seconds after they started.

Streaming Pattern Used

Every step uses getWritable() with multiple incremental writes followed by releaseLock():

export async function runToolTurn(state: WorkflowState, ...): Promise<WorkflowState> {
  "use step";
  const writable = getWritable<StreamUpdate>();
  const writer = writable.getWriter();
  try {
    // Multiple writes during step execution
    await writer.write({ type: 'data-tool_call', ... });
    
    // ... step logic (completes in < 5 seconds) ...
    
    await writer.write({ type: 'data-tool_result', ... });
    
    return newState;
  } finally {
    writer.releaseLock();
  }
}

This pattern is used across all 5 step functions, each doing 2-3+ writes per invocation.

Relevance to PR #678

I noticed that PR #678 (included in 4.0.1-beta.45) specifically addressed this:

"Fix stream serialization to resolve when user releases lock instead of waiting for stream to close. This prevents Vercel functions from hanging when users incrementally write to streams within steps."

I'm on 4.0.1-beta.50 which should include this fix, yet I'm still experiencing hangs. I'm planning to test 4.1.0-beta.52 to see if additional fixes were made.

What I Think Might Be Happening

I'm not certain what's causing the functions to hang, but I have two theories:

Theory 1: Streaming
Despite PR #678, there might be edge cases with multiple writes that still cause hangs. Or perhaps something about my specific pattern isn't being handled correctly.

Theory 2: Sandbox SDK
Some of my steps connect to a persistent Vercel Sandbox using Sandbox.get() to execute code. The sandbox stays alive across steps so I can maintain state. There doesn't seem to be a disconnect() method to cleanly release the connection—only sandbox.stop(), which would kill the VM entirely. This could be keeping the event loop active.

It could also be something else entirely that I'm not aware of.

Questions

1. Is the PR Fix stream serialization to resolve when user releases lock instead of waiting for stream to close #678 fix supposed to fully resolve the streaming pattern I'm using?
2. Are there edge cases with multiple writes that might still cause hangs?
3. Could the Sandbox SDK connection be keeping the event loop active?
4. Is there something else I should be doing to ensure functions terminate cleanly?

The Impact

This is a significant problem because I'm being charged for all that idle compute time. A workflow with 40 steps that each take 1 second is costing me 40 × 300 = 12,000 seconds of compute instead of 40 seconds.

Any insight into what might be causing the functions to hang—or how to make them terminate cleanly—would be hugely appreciated.

Thanks!

[pranaygp]

the sandbox sdk issue is a good bet on what's going on. if you releaseLock on the stream it should be closing. you can try to see if it reproduces in a step by commenting out any other code and only leaving in the code that write to the stream

separately, if you're using fluid compute, you won't be charged for the compute idle time. so even though the timeouts on the step routed are going to taint your logs and metrics, you shouldn't be billed for it

[TooTallNate]

Interesting. Based on the code you shared, #678 should have addressed it. If you could share a repro that would be very helpful.

[oabudayyeh]

Thanks guys. I'll try debugging the write stream and see if that fixes it. Helpful to know about the fluid compute billing.

@TooTallNate I just added you to the private repo (use the second invitation... the first one was a mistake). Would love if you could take a look. Here are some details to help point you in the right direction.

Thanks!

========
Here's a quick guide to the relevant files:

Workflow definition:

• workflows/specialist-finder/index.ts — the main workflow orchestrator (uses "use workflow" directive)

API routes:

• app/api/specialist-finder-v2/route.ts — POST endpoint that calls start() to kick off the workflow (~line 166)
• app/api/specialist-finder-v2/[id]/stream/route.ts — stream reconnection endpoint using getRun() / run.getReadable()

Step functions (all in lib/services/specialist-finder-v2/steps/):

Each of these uses "use step", getWritable<StreamUpdate>() with multiple writer.write() calls, and writer.releaseLock() in a finally block:

File	What it does	Sandbox usage
initialize-sandbox.ts	Creates sandbox, takes initial snapshot	Sandbox.create()
run-agent-batch.ts	Runs multiple agent turns per step	Sandbox.create() from snapshot
run-llm-turn.ts	Calls Gemini LLM	Sandbox.get() (keep-alive)
run-tool-turn.ts	Executes tool calls	Sandbox.get() (keep-alive)
archive-workspace.ts	Reads final report, saves to DB	Sandbox.create() + sandbox.stop()
report-generator.ts	Fallback report generation	Sandbox.create() from snapshot
cleanup-sandbox.ts	Stops sandbox	Sandbox.get() + sandbox.stop()

The two likely culprits for the hanging:

1. Streaming — every step does 2-3+ writer.write() calls before releaseLock(). This is the pattern PR Fix stream serialization to resolve when user releases lock instead of waiting for stream to close #678 was supposed to fix.
2. Sandbox SDK — several steps use Sandbox.get({ sandboxId }) to connect to a persistent sandbox for keep-alive / state preservation. There's no disconnect() method, so that open connection may be holding the event loop open after the step returns its state.

Config is in next.config.mjs (~line 19) where withWorkflow() is set up, and vercel.json has route config for the endpoint.

Let me know if you need anything else!