Stream event delivery to clients lags 2-3 minutes behind durable writes (steps finish in seconds)

Summary

Events written to a workflow run's stream become visible to readers only minutes later. The workflow itself completes its steps in seconds, but a client holding GET .../stream receives the events in ~120s reconnect cycles, and even a fresh stream read (replay from startIndex=0) does not show the recorded events until ~90s after the step finished.

Environment

• Vercel-managed Workflow (production, Fluid Compute), workflow spec v5
• Reached through the eve framework, which bundles @workflow/core — reproduced identically on eve 0.11.10 and 0.18.1, so this does not appear to be an eve regression
• Local dev runtime delivers the same streams in real time (<20s end-to-end), so this is specific to the hosted workflow backend

Measurements

Single structured-output turn; the model step completes in seconds — confirmed via /flow invocation logs.

Request-log pattern for the held-connection case: POST /session 202 in ~1s → /.well-known/workflow/v1/flow invocations complete within seconds → stream GET reconnects at exactly +120s intervals, and the result arrives only on a later cycle. Setting WORKFLOW_V2_TIMEOUT_MS=30000 had no effect on delivery timing.

The replay experiment is the interesting datapoint: since a brand-new streams.get() read at +60s still did not include events recorded at ~+10s, the lag appears to be on the write-visibility side of the streams backend, not in client reconnect behavior.

Impact

Interactive use (chat-style refinement against a durable session) is effectively blocked: every turn costs 2–3 minutes of waiting for a result that was ready in seconds. Possibly related to #943 (functions hanging after steps complete) if the underlying cause is stream finalization.

Happy to provide session ids / timestamps privately for backend-side tracing.

Start by reproducing the hosted behavior using the /flow invocation logs, a held GET .../stream connection, and fresh streams.get() reads with startIndex=0. Compare event-write and client-visible timestamps against the local runtime; done means recorded events become visible promptly instead of waiting through 90–120 second delays.