Module lag 

Production measurement of the merge-decision latency gate.

The Phase-0 gate (“p99 decision latency < 100 ms”) is asserted in the test suite, on a machine doing nothing else, against a synthetic workload. That is a check that cannot fail in production: the running daemon measured nothing, so a node that had drifted past the gate under real traffic would look exactly like one that had not.

LagMeter closes that. The writer thread records every accepted op at the single point where every accepted op passes, so a new submit path cannot be added and silently go unmeasured. Two latencies, because they answer different questions and PHASE0 measured them as an order of magnitude apart once sync_data landed:

• decision: dequeue -> append. The metric the gate is stated in.
• durable: dequeue -> acknowledgement, which includes the batch’s durability barrier. The number a submitter actually waits out, and the one an fsync stall shows up in. Gating on decision alone would have been the same non-check in a new place: the dominant cost sits entirely outside it.

A breach is durable >= gate, for that reason. decision breaches are counted separately so the gate as literally written stays checkable.

Structs

Breach

One op that missed the gate, as recorded for the lag log.

LagMeter

Shared latency record for one sequencer’s writer thread.

LagReport

What the meter has seen since the process started.

Constants

DEFAULT_GATE

The Phase-0 merge-decision latency gate.