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 4db5cf1
Browse filesBrowse the repository at this point in the historyBrowse files
refactor(stovepipe): Reuse issue status in history (#985)
## Summary
**What**:
- Reuse the same open/closed statuses for current issue records and
retained history.
**Why**:
- Remove two vocabularies for the same issue lifecycle. Current records
use open/closed, while history uses opened/resolved and requires a
translation. Sharing the status type makes the records consistent
without changing when issues open or close.
## Test Plan
- [x] Add unit tests.
- [x] Verify issue-history persistence against a real MySQL database.
## Revert Plan
- Revert this PR before enabling issue-history writes. The table layout
remains unchanged, with no existing history to convert.
## Issue Links
- [CODEM-607](https://linear.app/uber/issue/CODEM-607/build-analysis)
Copy file name to clipboardExpand all lines: stovepipe/core/messagequeue/README.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,8 +16,8 @@ Payloads are defined in proto3 (`proto/`, generated into `protopb/`) and seriali
16
16
17
17
`IssueTrack` binds to `TopicKeyIssueTrack` and identifies a persisted build and its queue. Notifications are partitioned by queue so both running and final issue-state updates share one serialized path, independently of build-partitioned analysis polling. The message carries identifiers rather than a failure collection; per-build observations are read through `BuildIssueStore.List`.
18
18
19
-
Publish only after detection and observation persistence succeed. With `finalize` unset, the notification permits opening newly detected issues, not resolution by absence. With `finalize` set, it requests final reconciliation after a successful terminal analysis. Publish that notification even when no failures were detected; terminal Build status alone does not replace the handoff. Publication retries must also follow duplicate observation writes so a crash between persistence and publication does not strand work.
19
+
Publish only after detection and observation persistence succeed. With `finalize` unset, the notification permits opening newly detected issues, not closing by absence. With `finalize` set, it requests final reconciliation after a successful terminal analysis. Publish that notification even when no failures were detected; terminal Build status alone does not replace the handoff. Publication retries must also follow duplicate observation writes so a crash between persistence and publication does not strand work.
20
20
21
-
Per-build observations accumulate historical evidence; finalization does not turn them into a replacement snapshot or override the detector's absence semantics. The reconciler must establish the authoritative final failure set and applicable validation scope before resolving issues, reject older requests, and ignore running notifications after finalization. Notification identity must distinguish new observations from finalization while remaining stable on publication retries. Business behavior follows the payload, not a parsed message ID.
21
+
Per-build observations accumulate historical evidence; finalization does not turn them into a replacement snapshot or override the detector's absence semantics. The reconciler must establish the authoritative final failure set and applicable validation scope before closing issues, reject older requests, and ignore running notifications after finalization. Notification identity must distinguish new observations from finalization while remaining stable on publication retries. Business behavior follows the payload, not a parsed message ID.
22
22
23
23
Only the handoff contract is defined. No publisher, consumer, topic registration, reconciliation progress, or writes to open issues and lifecycle history are enabled.
0 commit comments