This was generated by AI during triage.
Problem
Runtime plan application is not one consistent operation across the query engine. The QueryTracker applier updates the precompute engine, query engine, store, and shared planner configuration references through separate calls. A failure in one update can leave the other components on a different configuration.
The precompute runtime update also exposes the new ingest aggregation configuration before all workers have processed the corresponding update. Concurrent samples can therefore be routed using the new configuration while a worker still owns state created under the old configuration. GroupSamples carries no configuration generation or barrier marker.
Finally, when an existing aggregation ID changes materially, worker state and persisted outputs remain associated with that same ID. Old results can therefore be returned after the ID changes semantics, or old and new semantics can be mixed.
Desired outcome
Define and implement a runtime reconfiguration protocol that makes the configuration visible to ingestion, workers, query execution, stores, and planner context consistent. The protocol must specify ordering and failure behavior rather than relying on independent best-effort updates.
Acceptance criteria
- A failed update cannot leave the components permanently split across old and new configurations.
- In-flight samples cannot be processed with a stale aggregation state after a configuration-generation change.
- A materially changed aggregation ID cannot return persisted outputs produced under incompatible semantics; either IDs are immutable, old outputs are invalidated, or storage is versioned.
- The behavior is covered by store-backed and concurrent runtime-update tests.
Non-goals
Related: #505 and #665.
Problem
Runtime plan application is not one consistent operation across the query engine. The QueryTracker applier updates the precompute engine, query engine, store, and shared planner configuration references through separate calls. A failure in one update can leave the other components on a different configuration.
The precompute runtime update also exposes the new ingest aggregation configuration before all workers have processed the corresponding update. Concurrent samples can therefore be routed using the new configuration while a worker still owns state created under the old configuration.
GroupSamplescarries no configuration generation or barrier marker.Finally, when an existing aggregation ID changes materially, worker state and persisted outputs remain associated with that same ID. Old results can therefore be returned after the ID changes semantics, or old and new semantics can be mixed.
Desired outcome
Define and implement a runtime reconfiguration protocol that makes the configuration visible to ingestion, workers, query execution, stores, and planner context consistent. The protocol must specify ordering and failure behavior rather than relying on independent best-effort updates.
Acceptance criteria
Non-goals
Related: #505 and #665.