Symptom
attach_on_missing_create_is_idempotent_for_existing_file failed on the Windows leg of a main CI run, at hyperdb-mcp/tests/attach_tests.rs:312:10:
test result: FAILED. 24 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 60.48s
It appears intermittent
test (windows-latest) passed on the next main run (34062593527, commit 61fc766) with no code change touching attach.rs. So this is one observation, not a reproducible break, and it is recorded here so the evidence is not lost if it recurs.
Why it is worth investigating rather than dismissing
The neighbouring Windows behaviour in this area is genuinely different from Unix: Windows blocks concurrent opens of a locked .hyper file (see the comment at hyperdb-mcp/src/export.rs:439-442), and the attach/CREATE DATABASE IF NOT EXISTS path is exactly where that difference shows up. An idempotency test failing only on Windows is therefore consistent with a real platform-specific race around file creation or locking, not just runner noise.
Related context: the review of #281 concluded that the export lock path is unreachable on both platforms because export_hyper deletes the target before attaching, and suggested the live Windows issue may instead be the delete step's error classification. Whoever picks this up should read that analysis, since it covers adjacent code.
What is needed
A Windows runner. This could not be reproduced locally — all recent investigation has been on macOS, and the failure has not recurred in CI since.
Suggested first steps:
- Re-run the Windows leg repeatedly on an unchanged tree to establish a rate.
- Inspect
attach_tests.rs:312 to determine whether the assertion depends on file-handle release timing after the first attach.
Symptom
attach_on_missing_create_is_idempotent_for_existing_filefailed on the Windows leg of amainCI run, athyperdb-mcp/tests/attach_tests.rs:312:10:test (windows-latest)(id101555912364), at commit56bc0d0.test (ubuntu-latest)leg also failed, but on a different test (engine_recovers_after_hyperd_killed) — that one is now fixed by fix(mcp): publish a restarted hyperd endpoint to daemon.json before STATUS #286 / fix(mcp): daemon restart advertises the new hyperd endpoint before persisting it, and the restart tests' readiness gate never waits for the restart #284. This issue is only about the Windowsattach_testsfailure, which is unrelated.It appears intermittent
test (windows-latest)passed on the nextmainrun (34062593527, commit61fc766) with no code change touchingattach.rs. So this is one observation, not a reproducible break, and it is recorded here so the evidence is not lost if it recurs.Why it is worth investigating rather than dismissing
The neighbouring Windows behaviour in this area is genuinely different from Unix: Windows blocks concurrent opens of a locked
.hyperfile (see the comment athyperdb-mcp/src/export.rs:439-442), and theattach/CREATE DATABASE IF NOT EXISTSpath is exactly where that difference shows up. An idempotency test failing only on Windows is therefore consistent with a real platform-specific race around file creation or locking, not just runner noise.Related context: the review of #281 concluded that the export lock path is unreachable on both platforms because
export_hyperdeletes the target before attaching, and suggested the live Windows issue may instead be the delete step's error classification. Whoever picks this up should read that analysis, since it covers adjacent code.What is needed
A Windows runner. This could not be reproduced locally — all recent investigation has been on macOS, and the failure has not recurred in CI since.
Suggested first steps:
attach_tests.rs:312to determine whether the assertion depends on file-handle release timing after the first attach.