Designing a workflow engine you can watch run

The executor has no special case for any node type. It follows a single rule: an outgoing edge is active only if its source port appears in the node's result, and dead otherwise. A node whose incoming edges are all dead is skipped, and its own edges die too.

An If node fires true or false, so one branch dies. A node that fails with the continue error mode fires nothing, so everything downstream is skipped. A Merge waits until each incoming edge is settled. Branching, skip cascades and error ports all fall out of that rule, which is also why the canvas can explain every skipped node.

As the run executes, the engine publishes events such as a node starting, streaming tokens, succeeding or failing. Each persisted event gets a sequence number within the run, and the editor subscribes over server-sent events.

GET /runs/{run_id}/events?after_seq=42

If the connection drops, the client reconnects with the last sequence number it saw. It receives exactly the events it missed: none replayed twice, none lost.

A run is only replayable if you know what ran. Worfilo stores a snapshot of the graph with every run, next to each node's resolved inputs (with secrets redacted) and outputs. Reopening a run renders that snapshot on a read-only canvas, so replay stays correct even after the workflow has been edited or republished.

The frontend renders a JSON graph and subscribes to events; the backend validates and executes graphs and never knows about pixels. That split keeps the engine testable on its own, with fake nodes that never call a model, and means a graph runs the same from the editor or from a JSON file.