component_failed: a component reports a failure after it has started

[cressie176]

Context

Steve, 2026-09-27: a network component can fail after it has started (a postgres client emits an error). Passing the system into the component so it can call stop() is clumsy and gives it too much power. The system should be told, and the application should decide.

Behaviour

• A start function receives (components, { signal, fail }). Breaking change to the second argument; released as 0.2.0.
• fail(error) while the component's own start is in flight deems that start failed, exactly as its own timeout does: component_start_failed carries the error, the rest are skipped as failure, the system stops, start() rejects.
• fail(error) after the component started but while start() is still in flight announces component_failed with { name, error }, then fails the start with that error: the unreached are skipped as failure, the started (the failed component included) are stopped, start() rejects with the error.
• fail(error) once start() has resolved announces component_failed and nothing else. The application restarts, stops or ignores.
• fail after the component has stopped is ignored. fail twice announces twice. exitOn does not react.

Not covered

A component which does not notice the error and completes its start after being deemed failed has its stop skipped, as a timed-out one does today.

[cressie176]

Implemented in the commit "Let a component report that it has failed after starting" (not yet pushed). Feature: test/features/component-failures.md, three rules, six scenarios. Gates: 1288 steps pass, lint and typecheck clean, coverage unchanged at 100%.

Mechanism: the wait deems its own start failed if the report arrives before it settles, else forwards it; the system announces component_failed and, if a start deadline is live, records a failure interruption on it without firing any signal, so in-flight components are waited for. Reports for a component which is not started are ignored.

Breakages, each caught cleanly: the deadline not failed (start resolves, trace shows httpServer starting); a report during the own start treated as after (start hangs on the unresolved component, trace lacks component_start_failed); reports after stopping announced (trace gains a row).

Not closed: a report in the microtask between a start resolving and its component being marked started is dropped. Nothing real fires in that window.

Found while running the web app against Docker: with exitOn bound, restarting from a component_failed listener exits the process on the restart's stop, with code 0. Raised with Steve for a decision.