You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit f23a3c2
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: doc/rfc/stovepipe/project-status-api.md
+6-4Lines changed: 6 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,7 +17,7 @@ The request and response fields have the following API-level meaning. The publis
17
17
|`queue`| Yes | Identifies the queue in which to find the validation request. |
18
18
|`request_id`| ID lookup | Canonical positive decimal request ID returned by `Ingest`. |
19
19
|`change_uri`| URI lookup | Identifies the exact commit URI under validation. |
20
-
|`projects`| No | Consumer-defined project IDs whose results are requested. Omitted or empty returns all recorded project results. |
20
+
|`projects`| No | Consumer-defined project IDs whose results are requested. When omitted or empty, returns recorded project results, most broken first. |
21
21
|`page_size`| No | Limits one page of results for the requested projects. |
22
22
|`page_token`| No | Continues a previous page of results for the requested projects. |
23
23
@@ -29,7 +29,7 @@ The request and response fields have the following API-level meaning. The publis
29
29
|`updated_at_ms`| Records, in Unix milliseconds, the newest durable lifecycle or result record represented by the response. |
30
30
|`repository_breakage_degree`| Returns the whole-repository result when it is durably recorded. |
31
31
|`project_results_complete`| Indicates whether the implementation has durably finished producing results for the supplied project IDs. |
32
-
|`projects`| Returns recorded results for requested project IDs, or all recorded project results when none are supplied. |
32
+
|`projects`| Returns recorded results for requested project IDs in the supplied order, or recorded project results ordered by descending breakage degree, then ascending project ID when none are supplied. |
33
33
|`next_page_token`| Continues requested-project result pagination when another page exists. |
34
34
35
35
`request_state` is a stable public lifecycle vocabulary: `accepted`, `processing`, `succeeded`, `failed`, `cancelled`, or `superseded`. Clients must tolerate a future value. A terminal request state does not by itself mean that project results are complete.
@@ -64,15 +64,17 @@ The caller may supply the project IDs for which it wants recorded results. The A
64
64
65
65
When project IDs are supplied, the response includes only results for those IDs, in the supplied order, and paginates that list. An implementation may record results for every requested project, only requested projects with a non-green result, or another documented subset.
66
66
67
-
With no project IDs supplied, the response lists all recorded project results in project-ID order, excluding the repository fact. Results are a live view; restart pagination to discover facts recorded behind the cursor.
67
+
With no project IDs supplied, the response lists recorded project results by descending breakage degree, then ascending project ID, excluding the repository fact. If the result for the cursor project is missing, the API returns an error. Results are a live view; restart pagination to discover facts recorded before the cursor.
68
68
69
69
Each project result is an immutable validation fact keyed by queue, commit URI, and project ID. A result must identify the selected request. `project_results_complete` is false until the implementation has durably finished producing results for the supplied project IDs; a completed empty set is valid.
70
70
71
71
Callers use `project_results_complete`, rather than the presence or absence of an individual project result, to determine whether the implementation has finished producing results for the requested projects. `next_page_token` is empty only on the final page. A terminal lifecycle notification is emitted only after the repository result and any applicable project completion record are durable. If notification delivery fails, consumers can recover the same result through either endpoint.
72
72
73
73
## Implementation
74
74
75
-
Both endpoints return durable lifecycle summaries, the whole-repository fact when present, and recorded facts for requested projects in paginated request order, or all recorded project results in project-ID order when none are requested. `project_results_complete` remains false until a durable completion projection is available. Missing facts are omitted; an explicitly recorded zero degree remains present. `updated_at_ms` is the maximum timestamp of the summary and the facts represented on the page.
75
+
Both endpoints return durable lifecycle summaries, the whole-repository fact when present, and recorded facts for requested projects in paginated request order, or recorded project results by descending breakage degree then ascending project ID when none are requested. `project_results_complete` remains false until a durable completion projection is available. Missing facts are omitted; an explicitly recorded zero degree remains present. `updated_at_ms` is the maximum timestamp of the summary and the facts represented on the page.
76
+
77
+
A dedicated ordering mapping makes listing a bounded primary-key range read, not a sort over all facts. Listing reads at most `page_size + 1` ordering mappings and hydrates only the returned facts, plus the cursor fact on continuations. The continuation token identifies the last project; its immutable fact supplies the degree needed to resume this ordering.
0 commit comments