Module stage 

Boot-stage reporting: the running narration of a boot that takes minutes.

A big store spends minutes in WAL recovery, and until the record carried a stage there was nothing to read but silence: status could say a server existed but not what it was doing, and an operator watching a home could not tell a boot that was PROGRESSING from one that was STUCK.

A StageReporter is a cheap, cloneable handle on the incarnation’s own pid record. It is safe to hand into a blocking closure or another thread — the store build runs on the blocking pool and reports from there — and every report does two things at once: it writes the stage into the record (where aion server status and the launcher read it) and emits a tracing::info! line (where the log reader sees it). One story, told in both places, from one call.

Every report bumps stage_seq. That counter is the difference between “this boot is slow” and “this boot is wedged”: a reader that sees the sequence advance knows work is happening even when the stage token has not changed for minutes.

Structs

StageReporter

A cloneable handle for writing this incarnation’s boot stages.

Constants

STAGE_BINDING

The transport listeners are being bound. The last stage before serving.

STAGE_CONFIG

The machine token for the stage that resolves configuration — the first thing a boot finishes, and the one that names the home every later stage happens under.

STAGE_ENGINE_RECOVERY

The engine is recovering resident workflows from durable state.

STAGE_STORE_OPEN

The store is being opened: directories checked, the database handed to haematite.

STAGE_WAL_RECOVERY

The store’s shards are being materialized, which is where WAL recovery replays. This is the stage that takes minutes on a big store.

STAGE_WRITER_LOCK_WAIT

The open is blocked on the data directory’s writer lock, which a live process holds — a draining predecessor mid-handover, or another server on the same data directory.