Module replication_view 

What replication looks like from outside it — the one shape the console band, Admin.Stats and the log all read.

Why this exists rather than a direct reference to the replicator

Two problems, one answer.

1. Order. The gRPC control plane is built before the replicator is: the replicator subscribes to the event bus the server already has, and it is started last on purpose so that nothing above it can be slowed or failed by it. A surface that held an Arc<Replicator> could not be constructed.
2. The feature. mirror.rs is behind feature = "replication", and a build without it must still be able to say “no standby is configured”. A field that vanishes with a feature makes that sentence vanish too, and the whole point of this module is that silence is the bug.

So the view holds a closure, filled once by serve when the replicator exists. Nothing here names Replicator, and a build with no replication answers ReplicationReport::default — configured: false, which is a fact, not an absence.

The number that matters is the one that is missing

MEASURED: every configured standby received nothing from e31ab8f4 until the fix on 2026-08-30, and it said so five times out of five in a log line nobody read. The field that would have caught it on day one is StandbyRow::last_success_unix_ms being zero, and the sentence is “last successful replication: never” — which is why StandbyRow::never_synced is its own predicate and StandbyRow::describe gives it its own message rather than folding it into “stale”.

Structs

RefCoverage

★ How many refs a mirror does not carry — the number behind copied alice/korp 50 refs (94 not mirrored).

ReplicationReport

Everything a surface needs to draw replication, in one snapshot.

ReplicationView

A slot serve fills once the replicator exists.

StandbyRow

One standby’s state, flattened.

Enums

Verdict

★ What one standby’s row SAYS, in one word — decided here and nowhere else (one implementation), so the CLI row, the console badge, the appliance band and the alarm cannot disagree about the same standby.

Constants

BEHIND_AFTER_RETRY_MAX

How long outstanding work may sit before the standby is BEHIND, as a multiple of the retry ceiling.

STALENESS_FACTOR

How long WITH WORK STUCK ON IT and no success before a standby is STALE.

STALENESS_POLL

How often the staleness watch looks. Thirty seconds: the threshold is measured in tens of minutes, so the poll period is noise against it, and it costs a few atomic loads.

Functions

hms

HH:MM:SS from a count of seconds, saturating at three digits of hours.

is_stale

Is a standby that HAS synced now stale? The one computation behind StandbyRow::stale, as a pure function so it can be seen red without a live standby (measured, not asserted).

spawn_staleness_watch

The staleness alarm. One writer for the log line and the event-stream event (one implementation), so the console, journalctl, the UDP narration and every Events.Watch/SSE subscriber say the same thing about the same standby.