Flaky: scan_all_refused_returns_freeport_base sees another test's fixture discovery record

[StefanSteiner]

Symptom

scan_all_refused_returns_freeport_base failed on test (ubuntu-latest) at hyperdb-mcp/tests/daemon_tests.rs:1329:

expected FreePort(base), got Found(DaemonInfo { pid: 12345,
  hyperd_endpoint: "127.0.0.1:54321", health_port: 36131,
  started_at: "2026-05-20T10:30:00Z", version: "0.1.3" })
test result: FAILED. 62 passed; 1 failed; finished in 18.23s

Run 34076312106, on a PR whose diff is documentation, two benchmark comments, and one test comment — nothing that touches discovery. So this is a pre-existing isolation problem, not a regression.

Diagnosis

The values in that DaemonInfo are the tell. pid: 12345, version: "0.1.3", and hyperd_endpoint: "127.0.0.1:54321" are literal test-fixture constants, not anything a real daemon would report. But health_port: 36131 is an ephemeral port assigned at runtime.

So a different test in the same binary published a fixture discovery record, and this test's scan found it. cargo test runs tests within one binary on parallel threads by default, so two tests sharing a state directory will see each other's records. The scan is behaving correctly; it is being handed contaminated state.

Why it is worth fixing rather than re-running

This is the fourth distinct intermittent failure observed in this area today:

• engine_recovers_after_hyperd_killed — root-caused and fixed in fix(mcp): publish a restarted hyperd endpoint to daemon.json before STATUS #286 (a readiness gate that returned the pre-kill endpoint).
• attach_on_missing_create_is_idempotent_for_existing_file — Flaky on Windows: attach_on_missing_create_is_idempotent_for_existing_file (attach_tests.rs:312) #288, Windows only, needs a Windows runner.
• persistent_lock_keeps_mcp_available — observed timing out on a 2-second budget for a contended query; passes on re-run.
• This one.

Individually each looks like noise. Together they make the daemon suite unreliable enough that a red leg no longer carries information, which is the real cost — it trains everyone to re-run rather than investigate, and a genuine regression then hides in the noise. #286 is the proof that at least one of these was a real product bug rather than test flakiness.

Fix direction

Give every test that reads or writes discovery state its own HYPERDB_STATE_DIR, so no two can observe each other. Several tests already do this via TempDir, and the pattern is established — this looks like a case that was missed rather than a design gap.

Worth auditing the whole file for the same shape while in there: any test that calls discover(), write_discovery_file, scan_for_daemon, or resolve_port_scan without pinning the state directory. Note some tests deliberately use the process-wide ENV_LOCK; check whether that lock is being acquired consistently, since a test that skips it can race the ones that hold it.

Provenance

Observed on main-based CI at 05e993f. Verified that the PR's own diff cannot influence discovery.