Report this process's scheduled Consignado loops
Reports every scheduled Consignado loop this process knows about, whether or not it is running.
THE ANSWER IS PROCESS MEMORY. One request is served by ONE replica and reports that replica alone, so two reads of this operation may disagree, by design rather than by fault. ‘observed_replica’ is what makes the disagreement legible: it is an opaque, stable per-process tag, never a hostname and never a pod name. Counters and stamps reset when a process restarts.
The row set is fixed and complete: every loop in the inventory appears, including one this deployment did not compose. That is the point of the surface. Three conditions read differently, and conflating them is what leaves an operator acting on the wrong thing:
started true is a loop this process put on the scheduler. ‘passes’ and ‘failures’ count what it has done since the process came up.
started true is always accompanied by a ‘reason’ of enabled, whatever its family reports: a loop can be gated by its own boot flag rather than by its family’s, and a running loop is running.
started false with a ‘reason’ of flag_off, portal_store_absent or rail_client_absent is a loop this deployment never composed. The loop never reached the scheduler at all, so it has no counters and no stamps. ‘family’ names the operation family, and GET /v1/consignado/capabilities carries the same vocabulary for the family as a whole. The deployment flag behind the decision is deliberately not named: a flag name is operator material.
started false with a ‘reason’ of enabled, or with no reason at all, plus a ‘last_error_class’ of scheduler_refused, is the third condition: the registration reached the scheduler and the scheduler REFUSED it, so no worker was started. It is a wiring fault rather than a posture, and it is the one an operator has to escalate.
No loop runs a pass at process start. Every loop’s first pass is delayed and staggered per replica, so ‘last_pass_started_at’ is null for some time after a deploy on a healthy process.
‘last_error_class’ is the class of the MOST RECENT error, not the outcome of the last pass. It is not cleared by a later success, deliberately: a one-second loop would otherwise erase its own failure before anyone could read it. ‘failures’ beside it is what says whether the loop is still failing. The class names a mechanism and never carries the error message, because a pass error can carry a tenant identifier, a contract number or a rail payload.
‘overruns’ and ‘max_in_flight’ are populated only for the one fixed-rate loop and are null everywhere else, where null means ‘does not apply’ rather than ‘measured none’.
Nothing here is tenant data: the answer is identical for every tenant this process serves. The tenant is still derived from the validated identity, as on every other operation, and is never read from the request.
Authorizations
JWT bearer token issued by the identity provider.