Mid-run fan-out: one running step turns a list it could not know at build time into one job per item, then waits for them.

A static fan-out (Baton.Flow.FanOutSpec over $input/$context) knows N before anything runs, so Baton.Flow.Compiler emits N jobs in the insert transaction. When the collection is an upstream result — a claim list an LLM just produced — N is only knowable once that step has finished. This module is how the step that knows it creates the rest of the graph.

The expander is its own fan-in

The step is inserted once, as an expander, holding the logical step name and the node's declared deps. It runs twice:

1. Expand. Insert one child job per item, plus their workflow_nodes rows (fan_out_of = this step, item_index = position). Then append the children to this step's own deps and return {:snooze, _}.
2. Finish. The snoozed expander is woken by Baton.Reschedule when the last child settles — the ordinary promotion path, because the children are now genuinely its dependencies. Baton.Check has already confirmed every child is terminal, so finish/1 only has to record the manifest and decide the outcome.

Rewriting its own row rather than its readers' is what makes this safe. A reader's dependencies never change under it, so there is no window in which a reader observes the expander as complete while the children it must wait for are missing from its dep list. And because the expander sits in scheduled for the whole expansion, Baton.Completion counts it as pending — a workflow can never be announced finished with children still running.

Nothing downstream needs to know any of this happened. A reader declares a dep on the logical step exactly as it would for a static fan-out, and the flow runtime resolves $steps.<logical> to the ordered child results.

Idempotency

"Has this already expanded?" is answered by the children themselves — the existence of any workflow_nodes row with fan_out_of set to this step — never by scratch state that could be written separately from the rows it describes. The whole expansion (child jobs, child rows, the dep rewrite) commits in one transaction, so that question has only two answers and both are correct:

• Crash before commit — no children, so a retry expands from scratch.
• Crash after commit — children exist, so a retry skips straight to waiting for them.

The transaction additionally takes FOR UPDATE on the expander's node row before checking, so two runners of the same step (Oban rescuing a job whose original is still alive) serialize rather than double-expanding.

Outcome

finish/1 mirrors what a reader would have seen had the fan-out been static, so that ignore_discarded means the same thing either way:

• every child completed — the expander completes.
• any child did not — the expander stores its manifest and discards. A reader that set ignore_discarded: true proceeds and reads the partial list, exactly as it would with a directly-depended-on child that exhausted its retries; a reader that did not, cancels.

Because the expander must survive its children to make that decision itself, the expansion transaction also sets ignore_cancelled/ignore_discarded on the expander's own row. That loosening applies only from the moment the children are attached — the node's declared deps were already satisfied to get here, so nothing the author asked to be strict about is weakened.