The job status summary has one shape on every path
The rule
- A run's
job_status_summaryistotalfollowed by one integer counter per defined job status, in a fixed order, with no status omitted. - The same key set and order is published when the jobs are read successfully, when the run cannot be found, and when the read fails, the latter two all-zero.
- The job API's own
status_summarypublishes that same shape.
What it means
A run with no jobs yet, and a run whose jobs could not be read at all, both report the identical set of counters a run that ran normally would report — the same keys, in the same order, only every one of them zero instead of populated. That parity is what lets a caller treat "we do not know yet" and "there is genuinely nothing" the same way it treats "there were zero of every status," rather than having to branch on which of several build paths happened to answer. The counter set itself is derived from nothing narrower than every defined job status, so a status added to the vocabulary later cannot be forgotten by one path while another remembers it.
Example
No jobs have run yet, so every counter is zero and none of the vocabulary's statuses is missing.
{"total": 0, "idle": 0, "pending": 0, "running": 0, "completed": 0, "failed": 0, "cancelled": 0, "skipped": 0, "interrupted": 0}