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 2331282
Browse filesBrowse the repository at this point in the historyBrowse files
Summary:
First step toward keeping one full request projection in request_summary, with a small time-based lookup instead of duplicating lifecycle data for List. All required response data and receipt time are already captured.
### Changes
- Add request_receipt with only (queue, received_at_ms, request_id), its immutable storage contract, and gateway wiring.
- Ensure receipt keys after public projection writes, including unchanged/stale-log retries. Keep accepting receipts hidden and surface partial-write failures for existing retry handling.
- Keep List reads and the existing queue-summary projection writes in place for a safe cutover.
- Add storage, materializer, and integration coverage; document the transition in the RFC.
### Migration plan
1. Deploy the additive table before rolling out these writes. This PR populates receipt keys alongside the existing projection; it does not switch List reads.
2. Upgrade all writers, then backfill existing List membership from request_summary_by_queue keys. Validate keys against public authoritative summaries, exclude accepting receipts, and verify coverage before cutover.
3. In a follow-up, switch List to scan receipt keys and point-read request_summary. Preserve the API, time bounds, ordering, and page tokens; check page latency and keep old projection writes during the rollback window.
4. Once cutover is stable, stop duplicate projection writes, remove RequestQueueSummary and its store/mapper, and retire request_summary_by_queue after the rollback window. The final model stores one full projection plus immutable lookup keys.
Backfill tooling, read cutover, and duplicate-data removal are follow-up work. This preserves currently listed history without reconstructing requests predating the original read-model rollout.
Test Plan:
Before the internal rollout, provision the new table and confirm newly public requests produce matching receipt keys while List continues serving the old projection. Existing automated tests cover retries, concurrency, hidden receipts, and pagination.
Revert Plan:
Revert the writer rollout; List still uses the existing projection. Leave the additive table in place until no writers depend on it.
API Changes:
No RPC/proto changes. Gateway storage implementations must provide the new RequestReceiptStore accessor.
Copy file name to clipboardExpand all lines: doc/rfc/submitqueue/status-list-api.md
+16-2Lines changed: 16 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -77,7 +77,7 @@ The transport representation of these errors follows the gateway-wide RPC error
77
77
78
78
## Gateway-Owned Read Model
79
79
80
-
The gateway owns the append-only request log and three new logical read models. The orchestrator's request and change stores are pipeline working state with different retention semantics, so neither API reads them.
80
+
The gateway owns the append-only request log, materialized request summaries, and lookup stores. The orchestrator's request and change stores are pipeline working state with different retention semantics, so neither API reads them.
81
81
82
82
### Request Summary by Sqid
83
83
@@ -91,7 +91,7 @@ The key supports authoritative lookup and conditional status updates for one req
91
91
92
92
The queue projection is logically keyed by `(queue, received_at_ms, sqid)` and must support a bounded descending scan over `(received_at_ms, sqid)`. A backend may satisfy that contract with a reverse range scan or by descending-encoding the ordered key components; cursors always carry the original receipt time and sqid values.
93
93
94
-
The row duplicates the complete `List` response deliberately. A page is served by one bounded range scan rather than one follow-up authoritative-summary read per result. Status updates propagate from the authoritative sqid summary to this projection.
94
+
The current `request_summary_by_queue`row duplicates the complete `List` response so a page is served by one bounded range scan. Status updates still propagate to this projection during the receipt-lookup transition below; it is not the target storage model.
95
95
96
96
The logical key covers the `List` queue predicate, receipt-time range, newest-first ordering, and complete keyset cursor in one bounded scan.
97
97
@@ -162,6 +162,20 @@ There is intentionally no backfill from orchestrator working state or historical
162
162
163
163
The request-summary RPCs replace the former polymorphic Status shape with explicit ID and change-URI lookups. This is a source-breaking API change. The List RPC is additive.
164
164
165
+
### Receipt-Lookup Transition
166
+
167
+
The target model keeps the full projection only in `request_summary`. An immutable `request_receipt` lookup contains only `(queue, received_at_ms, request_id)` as its primary key. List will scan these keys and point-read the corresponding authoritative summaries, preserving the existing response, required time window, string-ID tie ordering, and page tokens. Receipt time and all response fields are already captured; no additional data collection is needed.
168
+
169
+
The first phase adds the lookup and its writes, without changing List reads or removing the old projection. After materializing a public summary and completing the existing URI/queue projection writes, the materializer ensures the receipt key exists, including on unchanged or stale-log retries. Hidden `accepting` receipts are excluded. A failed lookup write is returned through the existing projection-failure path.
170
+
171
+
Deploy the additive table before enabling these writes. To finish the transition:
172
+
173
+
1. Upgrade all writers, backfill existing List membership from the old table's keys, validate each key against its public authoritative summary, and verify lookup coverage.
174
+
2. Switch List to the receipt lookup plus authoritative summary reads, keeping old projection writes during the rollback window. This trades one page scan for one scan plus a point read per visible result; verify page latency before cutover.
175
+
3. Stop duplicate projection writes, remove `RequestQueueSummary` and its store/mapper, and retire `request_summary_by_queue` after the rollback window. Only the small immutable lookup key remains duplicated.
176
+
177
+
This backfill preserves existing List history; it does not reconstruct requests predating the original read-model rollout. Backfill tooling, read cutover, and removal are follow-up work.
0 commit comments