manager: a spawned process can still be reported failed_to_start

[kp2pml30]

Found by a review pass over feat/rework-manager-api. Verified in the code.

What

implementation/src/manager/run.rs:2297 (proc.spawn()? succeeds) — after that point, a failure writing execution data to the child's stdin does anyhow::bail!, so run_genvm_process returns Err and supervise_genvm publishes failed_to_start (run.rs:2341, :2108).

Scenario

Start an executor with extra_args: ["--bad-flag"] and an execution-data body large enough not to fit the pipe buffer. Clap exits and closes stdin while the manager is still writing. The select! then races:

• child.wait() wins → the run is reported finished;
• the stdin task's EPIPE wins → the run is reported failed_to_start.

Why it matters

The protocol defines the distinction by whether a process was created (docs/website/src/impl-spec/appendix/manager-socket.rst:223), and the process was created in both branches. tests/system/manager-socket/test.py:526 expects finished, so the test is load-bearing on losing the race.

Suggested fix

Record "spawned" state as soon as proc.spawn() returns, and classify every later failure as finished regardless of which arm of the select! fires.

[HusseinAdeiza]

Taking this one. I reproduced the mechanism on v0.6-dev and have a fix with a regression test that goes red against current main behaviour.

The race, confirmed. In run_genvm_process (implementation/src/manager/run.rs) the stdin select! has two arms that can fire at almost the same instant once the child has exited:

• the stdin writer returning EPIPE (failed to write execution data to child stdin), and
• child.wait() completing normally.

Whichever loses returns an error, and supervise_genvm reported every error out of supervise_genvm_inner as fail_to_start. So the same run reports finished or failed_to_start depending on a race the caller cannot observe. The existing system test at tests/system/manager-socket/test.py only passes because it happens to lose the race in the expected direction, which is why it reads as load-bearing.

The fix. The protocol already states the rule the manager should be applying (docs/website/src/impl-spec/appendix/manager-socket.rst): failed_to_start is reserved for runs that never reached a spawned executor, and the two events are distinguished by whether a process was created, which the manager knows exactly. The manager just was not recording it. I record the spawned state at the one point it is known, immediately after proc.spawn() returns, and let that decide the terminal event. No exit status exists when the failure precedes child.wait(), so the finished event carries a null exit_code, which the protocol permits for a run killed before its code was known. The error still goes to the log, since finished has no field to carry it.

Verification. The test drives report_run_failure, the function production calls for every error out of a run, so it covers the classification rather than a reimplementation of it. Neutralising the branch to the old behaviour fails it with exactly the reported symptom:

spawned run reported Event(FailedToStart { genvm_id: GenVMId(1), ...,
error: "failed to write execution data to child stdin: EPIPE" }),
expected a finished event

It also keeps a control case, so it would still fail if the branch were inverted and every failure became a finished. Full implementation lib suite: 80 passed, 0 failed. cargo fmt --check clean.

Branch is on v0.6-dev. PR to follow.

One thing worth deciding before I land it: I did not touch the system test. Making the race deterministic at that level (a body too large for the pipe buffer) is a larger change to shared test infrastructure and arguably a separate concern from the classification fix. Happy to do it if you would rather the protocol-level test also stopped depending on which arm wins.