Crate lora_wal 

Write-ahead log for LoraDB.

lora-wal is the additive durability layer that sits between lora_store::MutationEvent producers (the in-memory engine) and a durable byte stream on disk. It is deliberately separate from lora-store:

• lora-store stays storage-only — backends do not learn about logs, segments, or fsync. The mutation surface they already expose (MutationEvent + MutationRecorder) is the only seam.
• lora-wal owns segment files, framing, replay, and truncation. Consumers depending on the no-WAL story (wasm, embedded read-only) can avoid this crate entirely.
• lora-database glues the two together: it installs a WalRecorder onto the store and brackets each query with arm / commit / abort markers so replay sees query-atomic units even though the recorder fires per primitive mutation.

See docs/decisions/0004-wal.md for the full design and docs/operations/wal.md for operator-facing semantics.

Structs

Lsn

Monotonic log sequence number.

ReplayOutcome

Outcome of a full replay walk.

SegmentId

Monotonic identifier for a WAL segment file.

TornTailInfo

Wal

Live, append-side WAL handle.

WalRecorder

Adapter that lets a Wal act as a MutationRecorder on lora_store::InMemoryGraph::set_mutation_recorder.

Enums

SyncMode

Durability mode for committed transactions.

WalConfig

Configuration for opening a Wal.

WalError

Failure modes for WAL operations.

WroteCommit

Whether WalRecorder::commit actually wrote a TxCommit to the log. Read-only queries — those that never trigger MutationRecorder::record — return WroteCommit::No so the host can skip the surrounding flush() and avoid a per-query fsync just to record an empty transaction.

Traits

WalMirror

Optional side-effect after the WAL has successfully flushed.

Functions

replay_dir

Convenience: replay every *.wal segment in dir after sorting by the numeric prefix encoded in the file name.