Flaky on Windows: attach_on_missing_create_is_idempotent_for_existing_file (attach_tests.rs:312)

Start with hyperdb-mcp/tests/attach_tests.rs:312 and repeatedly run the Windows CI leg on an unchanged tree to establish whether the failure recurs. Read the adjacent locking behavior in hyperdb-mcp/src/export.rs:439-442 and the analysis from #281, then determine whether file-handle release or delete-error classification explains the assertion; done means the cause is addressed and the Windows test is reliable.

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

• Run: 34058959366, job test (windows-latest) (id 101555912364), at commit 56bc0d0.
• The same run's test (ubuntu-latest) leg also failed, but on a different test (engine_recovers_after_hyperd_killed) — that one is now fixed by #286 / #284. This issue is only about the Windows attach_tests failure, which is unrelated.

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:

1. Re-run the Windows leg repeatedly on an unchanged tree to establish a rate.
2. Inspect attach_tests.rs:312 to determine whether the assertion depends on file-handle release timing after the first attach.