Dev runtime: live-follow stream subscriber can miss the final events of a turn (turn.completed/session.waiting) — no event, no close, no error

Version: eve 0.22.1 (Next.js in-process mount via withEve, next dev; Node 24, macOS)

Summary

In the local dev runtime, a subscriber already attached to GET /eve/v1/session/:id/stream can permanently miss the final append burst of a turn — typically turn.completed followed by session.waiting. The connection stays open: no event is delivered, the response never closes, and no error is raised. The events ARE durably recorded — a second subscriber attaching afterward (or any replay from an earlier startIndex) reliably receives the full tail.

This strands any client whose settle detection waits for those events on that connection (ours parks in reader.read() indefinitely; we've since added a client-side inactivity deadline + reconnect as a workaround, and reconnect-with-replay always recovers in one hop).

Reproduction shape

Race-dependent, not deterministic — reproduced repeatedly on identical code (both failing and passing runs on the same tree):

1. Start a turn that streams for several seconds.
2. Attach a follower mid-turn: GET /eve/v1/session/:id/stream?startIndex=N (we hit this via a page reload that reconnects mid-generation; timing the attach so the turn's final append burst lands shortly after attachment maximizes the window).
3. Sometimes the follower receives all remaining content events but never the trailing turn.completed/session.waiting; the connection stays open and silent.

Parallel taps confirm the loss is per-subscriber: a second connection opened after settle always returns the complete log including the tail.

Where we suspect it lives

The dev stream endpoint appears to be a thin wrapper over getRun(id).getReadable({ startIndex }) (dist/src/execution/workflow-runtime.js). The observations are consistent with a wake-up race between the follower's live-tail notification and the final append batch: journal write succeeds, the attached reader is never signaled.

We have not observed this on deployed targets (Vercel Fluid/Workflows) across a full day of park/resume verification — it appears to be dev-runtime-follower-specific.

Expected

An attached follower either receives every event recorded after its position, or the stream closes/errors so the client can reconnect.

Happy to provide more detail or test a patched build.

Start with the dev stream endpoint and getRun(id).getReadable({ startIndex }) in dist/src/execution/workflow-runtime.js. Reproduce the mid-turn follower race using GET /eve/v1/session/:id/stream?startIndex=N and compare it with a later subscriber or replay. Done means an attached follower receives every recorded event after its position, or the stream closes or errors so the client can reconnect.