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 b81aae1
Browse filesBrowse the repository at this point in the historyBrowse files
Build analysis runs alongside status polling and recording. Hosts supply a queue-resolved detector factory. The reference service uses a no-op detector so the analysis stage is always wired without inspecting provider output; deployments replace the factory with their integration. No-op results do not establish build success or recovery.
4
+
5
+
After persisting a Build and its trigger occurrence, build publishes to buildsignal and buildanalysis. On completion, buildsignal persists status, releases the build slot, finalizes the Request, and publishes to record and buildanalysis. At each point, both publications are attempted even if one fails. Any errors are returned to the consumer framework for its retry or DLQ policy. Publication is not atomic: one destination can receive its message while the other publication fails. Start and terminal analysis notices use distinct deterministic message IDs and the same build-ID partition; retries of one notice deduplicate without suppressing the other.
6
+
7
+
Analysis reloads the Build and Request on each delivery, detects available issues, and creates immutable build-scoped observations. Observations already stored for the same build, task, and unit within a queue are not persisted again. A nonterminal Build holds for 30 seconds after each detection or persistence attempt, including failed attempts. Analysis errors remain visible in logs and metrics but do not consume queue retries while the build is active. A terminal Build receives detection and persistence before the delivery completes; failures use the subscription's normal bounded retry or DLQ policy. Malformed messages, invalid configuration, state-loading failures, and shutdown cancellation still return errors. The decision uses the status loaded before detection, so completion during a failed nonterminal pass leads to terminal processing on the next delivery.
8
+
9
+
If build-status polling cannot recover, its DLQ handler fails the Request and releases its slot, but leaves the Build at its last observed status because the actual build result is unknown. If analysis observes a terminal Request with a nonterminal Build, it reloads the Build in case completion advanced it between the two reads. If the Build is still nonterminal, analysis stops rather than continuing to poll a request that has ended. The analysis subscription keeps dead-lettering enabled. No consumer automatically replays analysis dead letters; failed messages remain available for investigation and an explicit replay decision. Analysis never changes request outcome or releases a build slot. Record remains independent of analysis success.
10
+
11
+
This branch records historical observations only; it does not maintain open issues, infer recovery from absence, or track issue lifecycle history.
Copy file name to clipboardExpand all lines: doc/rfc/stovepipe/workflow.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,6 +6,8 @@ The pipeline is a queue-driven chain of small, single-purpose controllers, in th
6
6
7
7
> **poll for a new head → ingest → process the build strategy → build → buildsignal → record whole-repo greenness (and any project results the resolver returns) → hook.**
8
8
9
+
The [build issue observation](steps/buildanalysis.md) branch runs alongside this chain. It accumulates issues while builds run and performs terminal analysis without gating record. The reference host wires a no-op detector; deployments supply a real detector factory.
10
+
9
11
There is no `analyze` controller and no `analyze` topic. A later project-analysis stage that would map a target graph onto another `build` pass is design only, described under [Designed, not built](#designed-not-built-project-analysis). `record` resolves project results inline on the same delivery that writes the repository fact.
0 commit comments