Fixed wall-clock waits on filesystem events share the watch-startup defect class

[dean0x]

Origin: #317 (mds watch startup race — compile-before-arm ordering bug)

The same defective synchronization primitive — a fixed wall-clock deadline polling for filesystem state, used as a synchronizer rather than as a failure bound — appears in two places that were deliberately left out of the watch.rs startup-race fix to keep that change reviewable:

Affected sites

crates/mds-cli/tests/cli_build.rs

Correction (2026-08-26): there is 1 affected site, not several — cli_build.rs:1138-1148. It is a bounded content-predicate poll, not a bare sleep-then-assert anti-pattern. The residual defect is only that it does not use the MDS_TEST_READY handshake that now exists for this purpose.

packages/bundler-utils/__test__/hmr-harness.mjs

waitFor / waitForContent helpers with timeoutMs = 5000 and intervalMs = 50, consumed by 4 HMR/watch end-to-end spec files (rollup/rspack/vite/webpack *-e2e.spec.mjs). Note: most call sites override the 5000ms default anyway.

These JS HMR specs are already known-flaky. They are Linux-gated (HMR_ENABLED = process.platform === 'linux' || process.env.MDS_HMR === '1'), which matches the Linux-only signature of the watch.rs bug described in #317, and makes it worth investigating whether they share the same root cause rather than merely the same symptom.

The general principle

Waiting on a deterministic readiness signal from the process — for example, a sentinel written to stdout/stderr, a stable inode state established by the process itself before signalling completion, or a watcher armed before the first write — is the durable fix class. Polling against a wall-clock timer is an approximation that fails when the system is slower than expected and masks the defect rather than removing it.

Scope of this issue

• Audit cli_build.rs fixed-duration waits and replace with event-driven or process-signalled synchronization.
• Audit hmr-harness.mjs waitFor/waitForContent call sites; if the flakiness signature matches mds watch silently loses edits made during startup #317, apply the same fix class. If the root cause is distinct, document it separately.
• No changes to watch.rs itself — those are tracked in mds watch silently loses edits made during startup #317.

[dean0x]

Evidence from the 2026-09-06 dependency sweep (v0.4.3 step A2, PRs #361 and #363)

Prior occurrences (Dependabot PRs, all unrelated to watch.rs)

PR	Head SHA	CI Run ID	Attempt	Failed Job	Test name in log	Panic Location
#355 fast-uri	b27a7f3	33976577844	1	Rust — fmt, clippy, test	yes	cli_watch.rs:1222:5
#356 maturin-action	d3d3ca9	33996276647	1	(success, no failure)	—	—
#360 wasm-bindgen-test	365bd7a	33976595173	1	Rust — fmt, clippy, test	yes	cli_watch.rs:1222:5
#333 rollup	7ff3b47	33753123463	1	Rust — fmt, clippy, test	yes	cli_watch.rs:1222:5

This sweep (2026-09-06 dependency updates)

CI Run ID	Head SHA	Conclusion	Attempt
33995227961	5d49318	success	1
33995706047	2cc7ea8	success	1
33996515648	12eb5c6	success	1
(lookup 13e2b9a)	13e2b9a	not retrievable	—
33997684678	8eaeaf8	success	1
33998018947	dry-run	success	1

Zero occurrences across the retrievable sweep runs; no gh run rerun --failed was needed; no test file was edited (handling per the A2 plan: rerun + evidence only, fix tracked here for phase C2).

Note

Per PF-026, a green re-run is not evidence that the test is a flake rather than a race — the discriminator is the panic line number against the assertion lines, which is why the panic locations above are recorded.