Uh oh!
There was an error while loading. Please reload this page.
docs(rfc): stovepipe record step design - #394
Conversation
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| | `Project` | Empty for the whole repository; stable project id for Phase 2 | | ||
| | `Degree` | Health degree in the closed interval `[0, 1]`; `0` is green and `1` is fully broken | | ||
| | `RequestID` | Request that established the fact | | ||
| | `CreatedAt` | Millisecond timestamp at which the fact was first recorded | |
There was a problem hiding this comment.
Thoughts on timestamp? We don't track timestamps elsewhere in the system but for these more long-term persisted facts, do we want to maintain some kind of timestamped history?
| A fact is written only when the request reaches a `succeeded` or `failed` verdict. A `cancelled` build is acked with no fact recorded. Callers gating deployments treat an absent fact as not green. | ||
| The fail-closed path also produces no fact, as the DLQ reconciler forces `failed` and never publishes to `record`. |
There was a problem hiding this comment.
I don't think never publishes to record holds when the fail-close originates in build_dlq. if build ack keeps failing, once retry_count hits MaxAttempts, the subscriber itself moves it to the DLQ, leaving one or more live poll chains behind in buildsignal step, and publishRecord fires anyway, record then writes a degree-1 fact regardless of the build result.
Design proposal for the
recordstep outlined in stovepipe's workflow.md