Module repair 

Inspecting and repairing a log file that a daemon is not holding.

Three things a log can be, and they want three different answers:

1. Intact. Every record decodes, every parent names the record before it, and seq counts from zero without a gap.
2. Torn at the tail. The final record was still being written when the machine stopped. Nothing was lost — the sequencer acknowledges only after crate::OpLog::sync returns — so this is repairable, and crate::FileLog::open already repairs it in place.
3. Damaged in the middle. A record that was once written whole no longer decodes, or the chain does not link. Not repairable here. Anything that made the file consistent again would do it by dropping ops that were acknowledged to somebody, and a log that silently loses acknowledged ops is worse than one that refuses to open. The answer is a restore from backup, and this module’s job is to say so precisely rather than to improvise.

Why this does not call FileLog::open

Because opening a log repairs it: a torn tail is truncated as a side effect of the constructor. A verify that ran through open would change the thing it was asked to inspect, and would report “intact” about a file it had just altered. Everything here reads the file with its own reader and writes nothing unless asked to.

What open does not check, and this does

crate::FileLog::open validates that each record decodes. It does not validate the chain: the parent/head comparison lives in crate::OpLog::append, on the write path, and has no counterpart on replay. So a log whose hash chain is broken opens perfectly well today. That gap is the reason verify exists.

Structs

ChainReport

What a read-only walk of the log found.

Repaired

What a tail repair did.

Enums

Fault

The first thing found wrong with a log, if anything was.

Functions

truncate_tail

Moves an unterminated final record into a sidecar and truncates the log to the last complete one.

verify

Walks the log and reports the first fault. Changes nothing.