> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # 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. ## OpenAPI ````yaml /en/openapi/v3-current/consignado.yaml get /v1/consignado/jobs openapi: 3.1.0 info: contact: email: contact@lerian.studio name: Lerian Studio url: https://lerian.studio description: >- OpenAPI 3.1 surface for Lerian Consignado — Dataprev. The API covers tenant credentials and rail configuration, worker margin, loan auctions and bids, contract registration and lifecycle, disbursement confirmation, portability, refinancing, renegotiation, FGTS guarantees, reconciliation, funds, assignments, usage, throughput, and event subscriptions. Secret material is written to the tenant secret store and is never returned by any operation. license: name: Lerian Studio General License title: Lerian Consignado API version: v1.0.0 servers: - url: https://br-consignado-gw.sandbox.lerian.net security: - BearerAuth: [] tags: - description: >- Per-tenant Dataprev credential custody and public rail configuration (upload, status, rotation, revoke, requester code, and worker portal base URL) name: Credentials - description: >- Tenant-scoped consignado gateway usage: priced billable-unit aggregation per competência name: Consignado Usage - description: >- Per-tenant streaming-hub subscription control-plane (list, create, get, rotate, revoke, and test delivery) name: Subscriptions - description: >- Dataprev payroll-rail surface: FGTS balance and authorization reads, the FGTS guarantee execution, contract suspension, reactivation and term changes, the rail's own contract documents, and the on-demand reads of leilão solicitações, escriturações, repasses and employment terminations name: Consignado Rail - description: >- Synchronous rail command surface: the operations a bancarizador without the lender drives over HTTP. Each shares its command implementation with the equivalent lender event trigger. name: Consignado Rail Commands - description: >- Gateway-owned disbursement confirmation: a client bank recording money it has ALREADY paid to a worker. It crosses no government boundary and proxies no Dataprev operation. name: Consignado Disbursement - description: >- Per-tenant self-service outbound Dataprev rail throughput: read and set this tenant's own requests-per-second, including a deliberate pause at zero name: Consignado Throughput paths: /v1/consignado/jobs: get: tags: - Consignado Scheduled Jobs summary: Report this process's scheduled Consignado loops description: >- 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. operationId: listConsignadoScheduledJobs responses: '200': content: application/json: schema: $ref: '#/components/schemas/ScheduledJobsResponse' description: OK '401': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: Unauthorized '403': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: Forbidden '429': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: Too Many Requests '500': content: application/problem+json: schema: $ref: '#/components/schemas/Detail' description: Internal Server Error security: - BearerAuth: [] components: schemas: ScheduledJobsResponse: additionalProperties: false properties: jobs: items: $ref: '#/components/schemas/ScheduledJob' type: array observed_replica: description: >- An opaque, stable per-process tag. Never a hostname and never a pod name: it exists only so an operator can notice that two answers came from two processes. type: string required: - jobs - observed_replica type: object Detail: additionalProperties: false properties: code: description: >- Stable, machine-readable domain error code scoped to the emitting service (format: -NNNN). examples: - ERR-0001 type: string detail: description: >- A human-readable explanation specific to this occurrence of the problem. examples: - Property foo is required but is missing. type: string errors: description: Optional list of individual error details items: $ref: '#/components/schemas/ErrorDetail' type: - array - 'null' instance: description: >- A URI reference that identifies the specific occurrence of the problem. examples: - https://example.com/error-log/abc123 format: uri type: string status: description: HTTP status code examples: - 400 format: int64 type: integer title: description: >- A short, human-readable summary of the problem type. This value should not change between occurrences of the error. examples: - Bad Request type: string type: default: about:blank description: A URI reference to human-readable documentation for the error. examples: - https://example.com/errors/example format: uri type: string upstream: $ref: '#/components/schemas/Upstream' description: >- RFC 9457 extension member: the error a proxied third-party provider reported. Absent unless the emitting service explicitly surfaced one. type: object ScheduledJob: additionalProperties: false properties: cadence_seconds: description: >- How often one pass is scheduled, in seconds, read from the loop's own interval provider at request time and clamped to its floor. format: double type: number failures: description: Passes that returned an error since this process started. format: int64 type: integer family: description: >- The operation family this loop belongs to, matching GET /v1/consignado/capabilities. Null when no capability family gates the loop. enum: - averbacao - averbacao_recovery - exclusao - correcoes - desembolso - cessao - leilao - portal - trilho - null type: - string - 'null' hot_cadence: description: >- True for the one fixed-rate loop: evenly spaced, start to start, with concurrent passes bounded. Every other loop runs pass then delay. type: boolean identity: description: >- The scheduler job identity, which is also the background-worker name this loop drains under. type: string last_error_class: description: >- The class of the MOST RECENT error, never the error message. It is not cleared by a later success: 'failures' beside it is what says whether the loop is still failing. type: - string - 'null' last_pass_ended_at: description: >- When the last pass finished. Null while any pass is in flight, and null before the first pass. format: date-time type: - string - 'null' last_pass_started_at: description: >- When this process last began a pass. Null before the first pass: no loop runs a pass at process start. format: date-time type: - string - 'null' max_in_flight: description: >- The concurrent-pass bound of the fixed-rate lane. Null on every other loop. Paired with 'overruns' it is what reveals that the purchased rate is not being achieved. format: int64 type: - integer - 'null' overruns: description: >- Ticks the fixed-rate lane skipped because its in-flight bound was reached. Null on every other loop, because a pass-then-delay loop cannot overrun: null means 'does not apply', never 'measured none'. format: int64 type: - integer - 'null' passes: description: Completed passes since this process started. format: int64 type: integer reason: description: >- Which mechanism decided this loop's presence, in the same closed vocabulary the capability read publishes. A loop this process started always reads 'enabled'; the other three values describe a loop that is NOT running, and they name the mechanism that stopped it. Null when the loop belongs to no family. enum: - enabled - flag_off - portal_store_absent - rail_client_absent - null type: - string - 'null' started: description: >- Whether this process actually started the loop. False covers two different things, which 'reason' and 'last_error_class' separate: a loop a flag switched off, and a loop the scheduler refused. type: boolean required: - identity - started - family - reason - cadence_seconds - hot_cadence - last_pass_started_at - last_pass_ended_at - last_error_class - passes - failures - overruns - max_in_flight type: object ErrorDetail: additionalProperties: false properties: location: description: >- Where the error occurred, e.g. 'body.items[3].tags' or 'path.thing-id' type: string message: description: Error message text type: string value: description: The value at the given location type: object Upstream: additionalProperties: false properties: code: description: The upstream provider's own error code, verbatim. examples: - E4001 type: string message: description: >- The upstream provider's own error message, verbatim (bounded, never its raw response body). examples: - account not found at provider type: string type: object securitySchemes: BearerAuth: bearerFormat: JWT description: JWT bearer token issued by the identity provider. scheme: bearer type: http ````