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 beb6b3d
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
+
## Start and completion notices
6
+
7
+
After persisting a Build and its trigger occurrence, build publishes to buildsignal and buildanalysis. On completion, buildsignal persists status, releases the build slot, records the Request outcome, and publishes to record and buildanalysis. Each pair of publications attempts both destinations even if one fails. Publication is not atomic: one destination can receive its message while the other publication fails.
8
+
9
+
Start and completion notices use distinct deterministic message IDs and the same build-ID partition. Retries of one notice deduplicate without suppressing the other. A held start delivery can delay the completion notice in that partition, but it also reloads Build status on every pass and can perform terminal analysis itself. Both notices may analyze the terminal Build; duplicate observations are safe.
10
+
11
+
Publication errors are returned through the producing stage's retry/DLQ policy. Analysis processing does not gate record, but notification publication is still part of the producing stage: a failed start publication can send the build-stage message to its existing fail-closed recovery path.
12
+
13
+
## Observations and polling
14
+
15
+
Each analysis delivery reloads the Build and Request, invokes the detector, and persists observations individually. Observations already stored for the same build, task, and unit within a queue are not persisted again. A persistence error can leave earlier observations stored; retrying does not duplicate them. Detector results accompanying an error are discarded.
16
+
17
+
After a successful pass, a nonterminal Build holds the delivery for 30 seconds; a terminal Build completes its delivery after persistence. The status read before detection determines whether the pass holds, so completion during detection requires another delivery to analyze the terminal Build. Analysis only accumulates historical observations: it does not maintain open issues, infer recovery from absence, or track issue lifecycle history.
18
+
19
+
## Requests that end without a build result
20
+
21
+
If build-status polling cannot recover, its DLQ handler fails a nonterminal Request and releases its slot, but leaves the Build at its last observed status. That recovery path does not publish a build-completion notice.
22
+
23
+
If analysis observes a terminal Request with a nonterminal Build, it reloads the Build before stopping: completion may have occurred between the initial Build read and the Request read. If the Build is now terminal, analysis proceeds. Otherwise it stops without detection or another hold. Analysis itself never changes Request outcome or releases a build slot.
24
+
25
+
## Analysis errors and dead letters
26
+
27
+
Analysis errors are returned to the normal consumer whether the Build is running or terminal; errors do not use the 30-second polling hold. The reference service uses backend error classification and the extended retry configuration: a maximum of 10 attempts, with retry delays of 5, 10, 20, 40, then 60 seconds, capped at 60 seconds. A successful hold resets failure accounting. Non-retryable errors and exhausted retries send the message to the analysis DLQ, so final analysis is attempted rather than guaranteed to succeed.
28
+
29
+
The analysis DLQ has no subscription or recovery controller. Dead letters remain subject to queue retention and require an explicit investigation or replay decision; they are not automatically retried indefinitely.
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 attempts final analysis after build completion. Record does not wait for analysis to succeed. 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