Firebreak.BootOrder (Firebreak v0.1.0)

Copy Markdown View Source

Boot order ≠ dependency order.

A static supervisor starts its children in list order, one at a time. A child's init/1 runs before the next sibling is started — so if child A synchronously calls a sibling that appears later in the list, that sibling isn't alive yet when A initialises. On first boot A's init blocks until it times out, then crashes; the supervisor retries in the same order and crash-loops.

This is invisible to the supervision tree (the tree says both are contained siblings) and easy to introduce by reordering children. We flag it by combining two facts Firebreak already has: the child order (exact from init/1 where available) and the in_init? coupling edges (static).

DynamicSupervisor children have no static start order, so this check applies only to Supervisor and Application roots.

Summary

Functions

analyze(modules)

@spec analyze([Firebreak.ModuleInfo.t()]) :: [Firebreak.Finding.t()]