Skip to content

GKGPipelineInvariantViolated

The query compiler reached a state that upstream validation should have prevented; the generated SQL could have been incorrect. Severity s3, fires after 1m.

The compiler rejected a query in a late stage (lowering, enforcement, codegen or pipeline) that earlier validation should have made unreachable. Each rejection is a compiler bug surfacing, and the same broken state could in another variant produce incorrect SQL instead of a rejection. Any non-zero count is anomalous.

The firing expression, on gkg_query_engine_compiler_rejected_total (emitted by the service, see the metrics catalog):

sum by (env, environment, stage) (rate(gkg_query_engine_compiler_rejected_total{failure_reason=~"lowering|enforcement|codegen|pipeline"}[5m])) > 0
  • Silence via Alertmanager filtered on the alertname.
  • Expected to never fire; each rejection is a compiler bug surfacing.
  • s3 during burn-in, promotion to s2 is planned alongside GKGAuthFilterMissing. The compiler rejected the query, so no incorrect SQL executed, but another variant of the same state might not be caught.

Split the rejections by stage to see which invariant broke:

sum by (failure_reason) (rate(gkg_query_engine_compiler_rejected_total{failure_reason=~"lowering|enforcement|codegen|pipeline"}[5m]))

Find the rejected query in the webserver logs (mode: webserver) around the alert window; the rejection log carries the failing query shape.

SymptomCauseAction
Rejections started with a deployNew compiler bug in the releaseRoll back the image tag; file an issue with the failing query
No deploy correlationLatent bug triggered by a new query shapeCapture the query from the logs; the fuzzers usually reproduce the class

There is no operational fix: this is a code bug in the query compiler. If the rejections started with a deploy, roll back the image tag. Capture the failing query from the logs and file an issue with it; the fuzzers (mise run fuzz:compile) can usually reproduce the class of failure.

  • None external: this is a query-compiler code bug by definition.

Escalate to context_systems (#f_orbit_dev) with the failing query attached. Treat a sustained rate as a rollback trigger, not something to wait out.

  • Alert rule (hand-maintained; keep the expr above in sync when tuning it).