Two tests in crates/attemptdb-storage/tests/crash.rs —
abort_wal_append_after_write and abort_manifest_after_tmp_write_leaves_a_tolerated_tmp_file —
failed on macos-x86_64 only, both with Locked on a writer open taken immediately after drop(db).
Closing the lock file releases the flock synchronously, so this should be impossible. What we know:
- 12 consecutive local runs on macOS ARM64 pass; the ARM64 CI job passes.
open_eventually in crash.rs now waits up to 5 seconds and counts retries, which separates a lagging lock release (milliseconds) from a genuinely leaked handle (budget exhausted → the fix belongs in the engine, not the test).- A later green Intel run reported zero retries, so the retry helper contributed nothing and the original failure is still unexplained.
What would close this
An Intel macOS run that reports a non-zero retry count, or a reproduction under load. If you have an Intel Mac and can run
cargo test -p attemptdb-storage --test crash -- --nocapture
in a loop and paste the output when it fails, that is the whole contribution.
Help wanted: we cannot reproduce this on the hardware we have.
Two tests in
crates/attemptdb-storage/tests/crash.rs—abort_wal_append_after_writeandabort_manifest_after_tmp_write_leaves_a_tolerated_tmp_file—failed on macos-x86_64 only, both with
Lockedon a writer open taken immediately afterdrop(db).Closing the lock file releases the
flocksynchronously, so this should be impossible. What we know:open_eventuallyincrash.rsnow waits up to 5 seconds and counts retries, which separates a lagging lock release (milliseconds) from a genuinely leaked handle (budget exhausted → the fix belongs in the engine, not the test).What would close this
An Intel macOS run that reports a non-zero retry count, or a reproduction under load. If you have an Intel Mac and can run
cargo test -p attemptdb-storage --test crash -- --nocapturein a loop and paste the output when it fails, that is the whole contribution.
Help wanted: we cannot reproduce this on the hardware we have.