🐛 fix(storage): issue no receipt when a directory flush fails

[gaborbernat]

A local-filesystem commit issued a DurabilityCapabilities::FILESYSTEM receipt whether or not the directory entry naming the blob ever reached disk. sync_parent swallowed the directory open behind if let Ok(...) and its sync_all behind let _ =, so publish returned success after the kernel refused the flush and commit_staged handed back a receipt. Replication and acknowledgement then weighed that receipt as proof of an entry a crash can still lose. #516 requires the parent-directory sync before any receipt, and the POSIX fsync contract says why.

The helper returns its failure now and every publication path propagates it, so a refused flush ends as an I/O error with no receipt. 🔒 Two cases needed more than plumbing. A fresh store has no digest fan-out, and create_dir_all leaves each level it creates as an unflushed entry in its own parent, so the store flushes those new levels from the leaf toward the first that already existed. A commit that finds matching bytes already resident flushes too: those bytes can come from a writer whose own sync failed, so their presence proves nothing about the entry naming them. That second rule is what lets a retry after a successful rename finish the durability step without touching the resident blob, the resumption path #1501 builds on.

flowchart LR
    Stage[Stage synced] --> Rename[Rename into digest path]
    Rename --> Flush{Directory flush}
    Flush -- ok --> Receipt[Placement receipt]
    Flush -- refused --> Error[I/O error, no receipt]
    classDef accent fill:#cfe4ff,stroke:#1f6feb,color:#0b1f3a;
    classDef warn fill:#ffe3a3,stroke:#d29200,color:#3a2c00;
    class Stage,Rename,Receipt accent;
    class Flush,Error warn;

Loading

Unix flushes the directory with fsync. Windows keeps the behavior it had, since it exposes no directory flush and NTFS orders the rename in the metadata log its recovery pass replays, which is what crates/peryx/src/operator/restore.rs already relies on. The issue also asked for a documented Win32 write-through path; I left that out rather than guess, because FlushFileBuffers rejects a handle opened with backup semantics.

Two behavior changes to watch. A store whose directories the process cannot open for reading now fails its commits instead of returning a receipt for a flush that never happened. A deduplicating write pays one extra directory fsync.

Closes #1391

[codspeed-hq]

Merging this PR will not alter performance

✅ 29 untouched benchmarks
⏩ 133 skipped benchmarks¹

---

_{Comparing fix/no-receipt-after-sync-failure-1391 (913ba53) with main (74eb4f9)}

Footnotes

1. 133 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩