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
Add the scorer seam from the speculation RFC, as a vendor-agnostic
extension interface under submitqueue/extension/speculation/pathscorer/.
The scorer computes each speculation path's predicted-success score from
the current state: the per-batch scores of the path's base batches
(entity.Batch.Score) and which of those dependencies have resolved
(landed or build-passed), plus optionally other signals. It is a
prediction over live state, so the controller re-runs it on every
respeculate right after reconciling status, and persists the result; the
scorer owns only the formula.
The controller hands it the batch's speculation tree directly — the
subject it scores. Any richer signal an implementation needs (dependency
batch scores, historical pass rates) is injected at its Factory, not put
in the signature. It never writes: its only output is per-path scores
([]entity.PathScore — path ID plus fresh score, an entity-level
seam-output type alongside the path-decision type), which the controller
merges into the tree and persists, staying the single writer of tree
state; structure and status never pass through the scorer. Scores are
probabilities in [0, 1] — the contract every implementation must
satisfy, enforced by the controller on consume.
This is the per-path scorer, distinct from the existing per-batch score
stage (`extension/scorer`) that sets entity.Batch.Score — the path
scorer consumes those to score whole paths.
Follows the repo extension contract: Factory.For(Config) (Scorer, error)
with Config carrying only QueueName. Includes README, gomock package,
and a programmable fake. The speculation RFC's seam descriptions are
updated to match the identity-keyed minimal-output contracts (and gain a
design-decision entry for assigned path identity). Interface only;
concrete impls and controller wiring are deferred.
## Stack
1. #337
1. #315
1. @ #316
1. #317
1. #320
1. #331
1. #332
1. #333
Copy file name to clipboardExpand all lines: doc/rfc/submitqueue/speculation.md
+6-4Lines changed: 6 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -187,13 +187,13 @@ Re-speculation needs no special undo path: the controller refreshes statuses, an
187
187
188
188
## Interfaces
189
189
190
-
The seams are vendor-agnostic extensions, each in its own package; the exact Go signatures live in the source. All are per-queue: the system hands a `Factory` the queue identity, and the factory builds the seam for that queue — so the queue is bound at construction and never re-passed to a method.
190
+
The seams are vendor-agnostic extensions, each in its own package; the exact Go signatures live in the source. All are per-queue: the system hands a `Factory` the queue identity, and the factory builds the seam for that queue — so the queue is bound at construction and never re-passed to a method. Persisted paths carry a controller-assigned identity, and every seam output names a path by that ID rather than restating its Base/Head split — each seam returns only its verdict, and everything else about a path stays controller-owned.
191
191
192
192
**Decision seams:**
193
193
194
-
-**Enumerator** (`extension/speculation/enumerator`) — given a batch ID and its ordered active dependencies, returns the batch's speculation tree *structure*: the candidate paths, each a Base/Head split. Pure and deterministic; sets no score and no status.
195
-
-**Scorer** (`extension/speculation/scorer`) — given the speculation tree and the current dependency batches, returns each path's predicted-success score. Called by the controller on every respeculate (during reconciliation) so scores track the live state — dependencies landing, dependency builds passing, siblings failing. Owns the score formula; combines the base batches' `Batch.Score` and their resolved/unresolved state (and optionally other signals).
196
-
-**Selector** (`extension/speculation/selector`) — given a speculation tree (with each path's controller-stamped status and freshly recomputed score), returns a per-path action (`Build` or `Cancel`) for the paths it chooses to act on. It reads status and score and emits actions only; paths it leaves alone are omitted. It is constructed with its **selection limit** and calls it to cap how many paths it builds in parallel.
194
+
-**Enumerator** (`extension/speculation/enumerator`) — given a batch and its ordered active dependencies, returns the batch's candidate paths, each a Base/Head split — structure only. Pure and deterministic; the controller assembles the persisted tree, assigning each path's identity and stamping its status.
195
+
-**Scorer** (`extension/speculation/pathscorer`) — given the speculation tree and the current dependency batches, returns each path's predicted-success score, keyed by path identity. Scores are probabilities in [0, 1]; the controller enforces the range when it merges them into the tree. Called by the controller on every respeculate (during reconciliation) so scores track the live state — dependencies landing, dependency builds passing, siblings failing. Owns the score formula; combines the base batches' `Batch.Score` and their resolved/unresolved state (and optionally other signals).
196
+
-**Selector** (`extension/speculation/selector`) — given a speculation tree (with each path's controller-stamped status and freshly recomputed score), returns a per-path action (`Build` or `Cancel`) for the paths it chooses to act on, each decision naming its path by identity, at most one decision per path. It reads status and score and emits actions only; paths it leaves alone are omitted. It is constructed with its **selection limit** and calls it to cap how many paths it builds in parallel.
197
197
-**Prioritizer** (`extension/speculation/prioritizer`) — given the queue's pending build candidates, returns the subset admitted to run, ranked by score plus any fairness policy. It is constructed with its **prioritization limit** and applies it itself. Operates queue-wide, across all of the queue's in-flight batches.
198
198
199
199
**Limit policies** — each a signal-driven "how much" seam returning a bound from build-resource and other signals:
@@ -206,6 +206,8 @@ The scorer, prioritizer, and the three limit policies are design-level here —
206
206
207
207
## Design decisions
208
208
209
+
**Persisted paths are referenced by assigned identity.** Each path entry in a persisted tree gets a controller-assigned, immutable, opaque ID when it is first written; scores, decisions, and durable links (such as the path→build mapping) all name paths by it. *Why:* seam outputs stay minimal — an ID plus a verdict — instead of restating structure, and cross-entity links stay valid however the tree is re-derived. *Rejected:* structural reference (restating Base/Head in every output) — couples every consumer to path structure and forces ordered-slice comparison everywhere; an ID derived from the structure — an ID that encodes structure invites parsing, and identity should be free to survive re-enumeration on the controller's terms.
210
+
209
211
**Two layers: decisions and limits.** Decision seams (enumerator, scorer, selector, prioritizer) — enumeration and scoring *describe* the tree, selection and prioritization *act* on it; limit policies (dependency, selection, prioritization) decide *how much*. *Why:* the "which" is qualitative policy that is stable, while the "how much" must scale with volatile build resources; separating them lets the resource-aware knobs move independently of the decision logic, and lets each be tested in isolation. *Rejected:* baking counts into each decision seam as constants — it hard-codes a policy that needs to breathe with CI capacity.
210
212
211
213
**Limits are signal-driven, and resources are the primary but not the only signal.** A limit is whatever its policy computes — from available capacity, and optionally historical pass rates, cost, time, or experiment flags. *Why:* speculation aggression should rise and fall with the build system, and the design should not foreclose other inputs. *Rejected:* a single fixed constant, or a static per-queue config value — neither can react to load.
Vendor-agnostic interface for scoring the paths in a batch's **speculation tree** — the predicted-success probability of each candidate bet, recomputed as the batch's world changes.
4
+
5
+
See the [Speculation RFC](/doc/rfc/submitqueue/speculation.md) for the end-to-end design and how scoring fits into the orchestrator pipeline.
6
+
7
+
## Scorer
8
+
9
+
A path's score is a **prediction**: *how likely is this bet to pay off, right now?* The scorer answers it from the current state — the per-batch success probabilities of a path's base batches (`entity.Batch.Score`, set by the score stage), which of those dependencies have already landed or had their build pass (resolved assumptions raise confidence), and optionally other signals such as how long the batch has waited or historical pass rates. The score is the common currency the [selector](../selector) and prioritizer both rank on, so keeping it current is what makes both act on the latest reality.
10
+
11
+
Because it is a prediction over live state, the scorer is **re-run on every respeculate**, right after the controller reconciles path status — so when a dependency lands, its build passes, or a sibling path fails, the surviving paths' scores are recomputed before anything is selected or prioritized. The controller drives *when* to rescore (it is part of reconciliation) and persists the result; the scorer owns the *formula*.
12
+
13
+
This is the per-**path** scorer, distinct from the per-**batch**[score stage](../../scorer), which sets `entity.Batch.Score`. The path scorer consumes those batch scores to score whole paths. The controller hands it the batch's **speculation tree** directly — the subject it scores — and any richer signal an implementation needs (the dependency batches' scores, historical pass rates) is injected at its factory, not passed in. It never writes: its only output is per-path scores, each naming a path by its ID, and the controller merges them into the tree and persists — the controller stays the single writer of tree state, and everything else about a path (structure, status) never passes through the scorer at all. Paths omitted from the result keep their last persisted score.
14
+
15
+
Scores are **probabilities in [0, 1]** — 0 is a bet certain to lose, 1 a bet certain to pay off. That is the contract every implementation must satisfy, and the controller enforces the range when it consumes the result. The selector and prioritizer rank on these values, so implementations sharing a queue must agree on this scale.
16
+
17
+
## Factory
18
+
19
+
A per-queue factory returns the scorer for a queue, following the repo's extension contract. It is handed only the queue identity; scoring knobs and read access to any extra signals are injected at construction by the integrator in the wiring layer, which resolves per-queue settings through `queueconfig`. Scoring itself stays config-free.
0 commit comments