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 1d76e2f
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
+12-2Lines changed: 12 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -64,15 +64,25 @@ 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 all recorded project results by descending breakage degree, then ascending project ID, excluding the repository fact. A dedicated ordering mapping makes this a bounded primary-key range read, not a sort over all facts. The continuation token identifies the last project; its immutable fact supplies the degree needed to resume this ordering. A missing cursor fact 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 all 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
+
The ordering mapping is keyed by `(queue, URI, degree_order, project)`. `degree_order` reverses nonnegative IEEE-754 degree bit patterns into an ascending integer key without rounding; positive and negative zero share one key. Binary identifiers preserve bytewise tie order. A page reads at most `page_size + 1` mappings and hydrates only the returned facts, plus the cursor fact on continuations. A mapping that disagrees with its authoritative fact is a consistency error.
78
+
79
+
The record controller persists the winning immutable fact before ensuring its mapping. Redelivery repairs missing mappings even when the fact already exists, and derives their keys from the stored degree rather than a losing candidate. Project-recording logs and downstream terminal notifications follow successful mapping writes. No cross-store transaction is required.
80
+
81
+
### Schema and rollout
82
+
83
+
The ordering table is additive; the original fact identity and primary key are unchanged. Install the table before deploying code that writes or reads it. Existing facts require a one-time backfill before index-based listing is enabled. `stovepipe/core/projectindex.Backfill` rebuilds one queue-scoped URI using bounded project-key scans and idempotent mapping writes; it is restartable and does not load all facts into memory.
84
+
85
+
A write-first rollout or a recording pause during cutover must prevent unindexed concurrent writes while historical backfill is verified. Do not switch readers merely because the new table exists: incomplete mappings would omit recorded facts. Schema deployment and historical backfill are operator-controlled, not performed by an RPC or service startup. Reverting readers does not require dropping the additive table.
0 commit comments