[retro 2026-10-12] Watch rebuild IO_PathNotFound on deployment/web/pages took a runtime down mid-suite (upstream mxcli candidate) #285

Info for research (no PR requested). Upstream mxcli candidate.

What happened

During a journey sweep, a watch rebuild failed and the runtime for one app went down. The sweep's remaining journeys failed as infrastructure faults and had to be rerun after a ~40s manual restart.

Error shape (path trimmed to the repo-relative part):
build failed: AggregateException_ctor_DefaultMessage (IO_PathNotFound_Path, <app>/deployment/web/pages/<Module>.<Page>.js)

Numbers

• 74 occurrences in 17 background-shell outputs in one night.
• Seen in two of the three apps, with up to three page bundles named in one message.
• One of them took the runtime down mid-suite; the others left the app serving stale or 404ing pages until restart.

Trigger

SCSS or page edits landing while the incremental web-client bundler still had a build in flight; the bundler read page bundles that the previous build had just removed.

What worked

A full restart recovers (about 40s). The failure is loud in the watch output.

What was slow

It killed a running suite and the agent that owned the suite had to be told to rerun only the infrastructure failures. Nothing in the harness distinguishes "app crashed" from "journey failed".

Research

1. Can the bundler retry, serialise rebuilds, or tolerate a missing bundle instead of throwing?
2. Should a failed watch build leave the previous runtime serving, never take it down?
3. Could the journey harness probe the app between journeys and mark "app down" separately from FAIL?

🤖 Generated with Claude Code