Repository navigation
test: drive the fault-injection backend through the full save/WAL/recovery paths #390
Description
Problem
src/storage/backend/fault_inject.rs (FaultInjectingBackend) exists, but only a small fault_injection_tests module in persistent_facts.rs uses it. No integration test covers these failures at every point in save(), WAL append, checkpoint and recovery:
- short writes
- torn pages
fsyncfailure (EIO)- ENOSPC
fsync failure matters most. After a failed fsync, the page cache may already have dropped the dirty pages. Retrying the fsync can then report success even though the data was never written (the PostgreSQL "fsyncgate" problem).
Ask
- Add a test matrix that injects each fault at each write or sync call during
transact,checkpointandsave(). After each fault, reopen the database. The data must be either the last committed state or a clear error, and must never be wrong. - Decide and write down what happens after an fsync failure. The safe choice is to poison the handle and make the caller reopen, not to retry.
- Add an ENOSPC test in which the disk fills halfway through a checkpoint.
Activity
test(storage): crash at every write/sync in save() loses no checkpoin…
test: drive faults through the whole save/WAL/recovery path; never re…
test: count checkpoint writes on a closed copy; Windows cannot copy a…
Merge pull request #515 from project-minigraf/test/390-fault-matrix
adityamukho commentedon Oct 10, 2026
Done on
v3in #515: a test-only fault plan, thesrc/fault_matrix.rsmatrix (EIO, torn/short writes, sticky ENOSPC, failed fsync with and without lost writes, at every write and sync of transact, checkpoint, close and rebuild), and the decision that a failed checkpoint is never retried on the same handle (STG-046, documented in ERROR_REFERENCE andMinigraf::checkpoint). It found #513 (fixed in #514, backported in #516).