feat(stovepipe): Track issues in bounded passes

Author: prathshenoy

stovepipe/controller/issuetrack/BUILD.bazel

@@ -6,8 +6,12 @@ go_library(
     importpath = "github.com/uber/submitqueue/stovepipe/controller/issuetrack",
     visibility = ["//visibility:public"],
     deps = [
+        "//platform/base/id:go_default_library",
+        "//platform/base/messagequeue:go_default_library",
         "//platform/consumer:go_default_library",
         "//platform/metrics:go_default_library",
+        "//stovepipe/core/loader:go_default_library",
+        "//stovepipe/core/messagequeue:go_default_library",
         "//stovepipe/entity:go_default_library",
         "//stovepipe/extension/storage:go_default_library",
         "@com_github_uber_go_tally//:go_default_library",
@@ -18,11 +22,14 @@ go_library(
 go_test(
     name = "go_default_test",
     srcs = [
+        "delivery_test.go",
         "issuetrack_test.go",
         "pending_change_race_test.go",
     ],
     embed = [":go_default_library"],
     deps = [
+        "//platform/base/messagequeue:go_default_library",
+        "//platform/consumer/mock:go_default_library",
         "//stovepipe/core/messagequeue:go_default_library",
         "//stovepipe/entity:go_default_library",
         "//stovepipe/extension/storage:go_default_library",

stovepipe/controller/issuetrack/README.md

@@ -1,5 +1,13 @@
 # Issue tracking
 
+## Notifications and bounded work
+
+Notifications identify a queue, build, and whether analysis is final. They share one queue partition and consumer group. Pending work is finished before another source is accepted. With no pass pending, request ingest order rejects older builds, finalized requests reject later refreshes, and completed owning notifications are ignored on replay. A notification that helps another pass finish holds once more for its own work.
+
+Each delivery processes at most 100 distinct task/unit keys, including a resumed change and closed records. Refresh opens newly reported issues but does not close by absence. Finalization also scans issue states: reported issues stay open or reopen, absent open issues close, and closed records remain untouched. A canceled build cannot close by absence because validation may not have run. Every scanned key advances progress, including closed records; a full read requires another batch to establish exhaustion.
+
+Before changing an issue, planning reads its current version and saves the exact intended transition using progress CAS. No issue write happens if that save loses a race. The saved change retains its original expected version and history timestamp. Final handoff requires successful complete detection and persistence, and the request's recorded winning terminal build. Finalization uses accumulated per-build issues, not just the latest detector response.
+
 ## Applying a saved change
 
 The controller applies one `PendingIssueChange` already saved in the queue's progress record. Expected issue version zero means create-if-absent. A positive version means update that exact version. A retry never adopts a newly loaded version to execute old instructions.
@@ -10,4 +18,4 @@ A replacement must finish that same pending change before accepting later work.
 
 All writes use complete primary keys. There are no cross-record transactions, leases, snapshot indexes, or additional operation counters. Records and versions must not be deleted or reset while an old delivery could resume. All issue-state writers must follow this protocol.
 
-This layer does not scan build issues, receive queue messages, publish repairs, or register a runtime consumer. Planning, delivery orchestration, and terminal recovery are separate additions.
+The reference host does not register this consumer. Repair publication and terminal recovery remain follow-ups. Permanently failing pending changes block later issue-tracking work and require recovery; skipping the saved change is not safe. A future repair handoff must persist its prerequisites and publish before clearing the change that owns that obligation.