Skip to content

feat(stovepipe): Materialize request issue results - #1024

Merged
prathshenoy merged 1 commit into
mainfrom
request-issues-recording
Nov 9, 2026
Merged

prathshenoy merged 1 commit into
mainfrom
request-issues-recording

Conversation

@prathshenoy

@prathshenoy prathshenoy commented Nov 6, 2026 •

Copy link
Copy Markdown
Contributor

Summary

What:

  • Generate request-level issue summaries from the shared issue history.
  • Record repeat reports during normal processing and dead-letter recovery.

Why:

  • Keep request results consistent with accepted issue updates after failures. Retaining an event and repairing its projections before advancing the cursor lets normal processing and recovery finish interrupted writes without inventing reports.
  • Distinguish newly covered requests from historical requests whose issue summaries were never recorded. Recording coverage begins only after all issue-tracking workers use the updated contract.

Test Plan

  • Add unit tests.
  • Verify replay rebuilds missing summaries against a real database.
  • Verify stale workers cannot reopen issues or corrupt request results after recovery and a newer build.

Revert Plan

  • Revert dependent request-result reads and this PR. Operational issue state and retained issue history remain available; summary rows can remain unused.

Issue Links

Stack

  1. feat(stovepipe): Store request issue summaries #1023
  2. feat(stovepipe): Retain repeat issue reports #1027
  3. feat(stovepipe): Materialize request issue results #1024
  4. feat(stovepipe): Add request issue lookups #1025

@prathshenoy
prathshenoy force-pushed the request-issues-recording branch from 4dca0b9 to ae8d7c3 Compare November 6, 2026 18:46
@prathshenoy
prathshenoy added this pull request to stack #1026 November 6, 2026 18:46
@prathshenoy prathshenoy changed the title feat(stovepipe): Record request issue results feat(stovepipe): Materialize request issue results Nov 6, 2026
@prathshenoy
prathshenoy force-pushed the request-issues-recording branch 2 times, most recently from 43db33c to 8054163 Compare November 6, 2026 19:43
@prathshenoy
prathshenoy removed this pull request from stack #1026 November 6, 2026 19:43
@prathshenoy
prathshenoy changed the base branch from request-issues-storage to request-issue-log-storage November 6, 2026 19:43
@prathshenoy
prathshenoy added this pull request to stack #1028 November 6, 2026 19:43
@prathshenoy
prathshenoy marked this pull request as ready for review November 6, 2026 20:59
@prathshenoy
prathshenoy force-pushed the request-issues-recording branch from 8054163 to d048cfd Compare November 6, 2026 21:33
@prathshenoy
prathshenoy force-pushed the request-issues-recording branch from d048cfd to 27d305a Compare November 6, 2026 23:23
@prathshenoy
prathshenoy added this pull request to the merge queue Nov 9, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Nov 9, 2026
Base automatically changed from request-issue-log-storage to main November 9, 2026 14:00
@prathshenoy
prathshenoy force-pushed the request-issues-recording branch from 27d305a to 96c3896 Compare November 9, 2026 14:00
@prathshenoy
prathshenoy added this pull request to the merge queue Nov 9, 2026
Merged via the queue into main with commit 195f392 Nov 9, 2026
20 checks passed
@prathshenoy
prathshenoy deleted the request-issues-recording branch November 9, 2026 14:14
Tmwakalasya pushed a commit to Tmwakalasya/submitqueue that referenced this pull request Nov 11, 2026
## Summary
**What**:
- Add paginated storage for request-level issue summaries.
- Support conditional updates as a request's issue results advance.

**Why**:
- Provide an efficient way to list what a request introduced,
encountered, or closed. Existing issue history is organized by issue
rather than request, so reconstructing each request's results on every
read would require scanning unrelated history.
- Allow the materializer to retain a closure when an older opening or
report is replayed later. Version-guarded replacements support that
ordering without a transaction.

## Test Plan
- [x] Add unit tests.
- [x] Verify storage and conditional updates against a real database.

## Revert Plan
- Revert dependent readers and materialization first, then this PR. The
unused summary table can remain.

## Issue Links
-
[CODEM-607](https://linear.app/uber/issue/CODEM-607/build-analysis-issue-track)

## Stack
1. uber#1023
1. uber#1027
1. uber#1024
1. uber#1025
Tmwakalasya pushed a commit to Tmwakalasya/submitqueue that referenced this pull request Nov 11, 2026
## Summary
**What**:
- Extend issue history to retain repeat reports and original opening
references.
- Keep repeat reports from changing lifecycle status or transition
timestamps.

**Why**:
- Retain evidence that later validation builds encountered an
already-open issue. Those reports are needed for request-level existing
results, but must not reopen an issue or move its transition timestamp.
- Preserve the opening in each new event so replay can identify the
occurrence after the issue has closed or reopened. Deploy the additive
history column before updated consumers; existing lifecycle history
remains readable without backfilling it.

## Test Plan
- [x] Add unit tests.
- [x] Verify event retention and queue isolation against a real
database.

## Revert Plan
- Revert dependent reporting and projection changes first, then this PR.
Retained repeat-report events and the additive column can remain unused.

## Issue Links
-
[CODEM-607](https://linear.app/uber/issue/CODEM-607/build-analysis-issue-track)

## Stack
1. uber#1023
1. uber#1027
1. uber#1024
1. uber#1025
Tmwakalasya pushed a commit to Tmwakalasya/submitqueue that referenced this pull request Nov 11, 2026
## Summary
**What**:
- Add paginated request-level issue lookups with new, existing, and
closed classifications.
- Report whether results are in progress, complete, incomplete, or
unavailable.

**Why**:
- Let consumers explain which issues a request introduced, encountered,
or closed without reconstructing that history from the queue's current
state.
- Make partial and unavailable results explicit so an empty response is
not mistaken for a clean request. Completed request results remain
independent of later issue changes.

## Test Plan
- [x] Add unit tests.
- [x] Verify materialized results, pagination, and completion status
through the running service.

## Revert Plan
- Revert this PR. Recording continues independently, and the stored
results remain available for a later reader.

## Issue Links
-
[CODEM-607](https://linear.app/uber/issue/CODEM-607/build-analysis-issue-track)

## Stack
1. uber#1023
1. uber#1027
1. uber#1024
1. uber#1025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants