Module stream 

The stream driver: chunked execution through run_node’s primitives.

One execution site is the runtime’s core invariant, and streaming is no longer the exception: every chunk of every node goes through the same three primitives the topological walk composes — output_key (the memoization guard and the one key derivation), compute_node (panic containment around the only filter-vs-step match) and store_output (provenance on every write). What lives here is only what is genuinely streaming’s: chunk flow per StreamMode, the evolving state carried between chunks, barrier buffers and their flush, and the per-node event bracket.

Events. One NodeStarted when the first chunk reaches a node, one NodeCompleted per started node at StreamRun::finish with an aggregated summary (stream: N chunks, H hits, M misses), and a real NodeFailed naming the chunk on error — so an upstream span left open means exactly what it means everywhere else: the run died mid-node. Per-chunk cache hit/miss events are deliberately not emitted (hundreds of standalone spans would drown a reader); the counts travel in the summary. A per-chunk NodeStarted under made-up ids (model#chunk_3) was tried once and reverted.

Evolving. The forward’s output value doubles as the next chunk’s state — a documented conflation. Separating them needs a step(chunk, state) -> (out, state) API on filters, which is a user-facing change this driver deliberately does not smuggle in.

The worker’s remote streaming holds a StreamRun (plus its Context) alive between WebSocket messages — which is why the type is public and why the state that must survive between chunks lives here rather than in the plan walk.

Structs

StreamOutput

Incremental concatenation of chunk outputs.

StreamRun

Drives one stream plan: chunks in, one concatenated output out.

Functions

materialize_buffer

Concatenate tensor chunks along first dimension.