pub const REPOSITORY_SLOT_AVAILABLE_CONDITION: &str = "RepositorySlotAvailable";Expand description
Condition recording whether this run holds a slot in its repository’s
mover-Job pool (spec.concurrency.maxConcurrentJobs). False with
WAITING_FOR_SLOT_REASON means the run is parked at phase: Pending
because the pool is full; True with SLOT_ACQUIRED_REASON means it was
admitted and its Job launched.
Written by exactly three kinds — Snapshot, RepositoryReplication and
SnapshotReplication — and each carries BOTH arms. Those are the run kinds
the gate can hold, so each can be parked at False and later healed to
True.
A Restore never carries this condition at all, in either arm. A restore
is a recovery in progress, so it is ALWAYS admitted — holding one behind a
queue of routine backups is exactly backwards. Its mover Job is still
labelled into the pool and still COUNTS against the cap (so a restore
displaces backups rather than adding to them), but the restore reconciler
never consults the gate and writes no slot condition of its own.
Deliberately NOT a crate::gates::StructuralGate. The registry’s
contract (see the gates module doc) is “blocked on something only a human
can change” — a park that never self-heals. This one always does: the pool
drains as in-flight Jobs finish, and the parked run is admitted on a later
pass with no human action at all. Registering it would make kubectl kopiur doctor report a wedge every time a busy repository is merely doing its job,
which is the exact inverse of the false-green defect the registry exists to
prevent. A pool that never drains is a stuck Job problem, and doctor’s
existing stuck/failure checks are what surface that.