Module caught_up 

Support for checking whether clusters/collections are caught up during a 0dt deployment.

During a zero-downtime upgrade the new environmentd boots read-only and reports “ready to promote” once its clusters have caught up with the leader generation. Coordinator::maybe_check_caught_up runs that check on an interval (see with_0dt_deployment_caught_up_check_interval). We call one such run a “tick”, and the term is used throughout this module.

A point-in-time caught-up check is not enough on its own: a crash- or OOM-looping replica can momentarily look hydrated and caught-up, and cutting over right then drops us straight into a crashing replica. On top of the per-tick caught-up classification we therefore run a stability gate. Once a cluster is genuinely caught-up it must stay caught-up and have all replicas healthy for a configurable period before we report it ready. Any disruption (a replica not Online, a status flap between ticks, or a replica restart) resets the streak, so a crash-looping replica never accumulates the required stable time. ClusterStabilityState holds the per-cluster gate state across ticks.

Structs

CaughtUpCheckContext

Context needed to check whether clusters/collections are caught up.

ClusterHealthSnapshot 🔒

A point-in-time view of a cluster’s replica health, derived from the in-memory mirror of orchestrator-reported replica statuses.

ClusterStabilityState

Per-cluster state for the stability gate, retained across caught-up checks.

StabilityObservation 🔒

Outcome of folding one health snapshot into a ClusterStabilityState.

Enums

ClusterCaughtUpStatus 🔒

How a cluster relates to the 0dt caught-up check on a given tick.

StabilityBlocker 🔒

Why a caught-up cluster is being held back by the stability gate on a given tick.