Area: pipes · admin-api — friction · found via WaveHouse-Stats dogfooding (building the stats page's 14 analytics pipes)
Expected: a way to validate/preview a pipe's SQL — parse + bounded execute (or an EXPLAIN) as a given role — without publishing it as a live named pipe, mirroring the existing policy.validate.
Actual: POST /v1/admin/policy/validate dry-runs a policy (internal/api/router.go:180), but pipes have no counterpart — the admin surface is only List/Get/Put/Delete (internal/api/router.go:183-186) plus Execute (:151-152). PUT /v1/admin/pipes/{name} is create-or-update against the live registry, and pipe SQL only ever runs when executed. So the only test loop is: edit the pipe → PUT it live → curl it. A syntactically-bad or pathological pipe is only caught after it is published (it errors rather than crashes, but it is in the registry).
Impact: "test" and "publish" are coupled — CI can gate policy files but not pipe SQL. Stats worked around it by standing up a local ClickHouse with a sample gh_events table and validating there first; an adopter without that harness iterates against their live registry. Low severity (pipes are cheap and reversible), but it's a DX gap the product could obviate.
Note: a validate path would also give #406's dummy-bind EXPLAIN diagnostic a natural home — same "analyze this pipe's SQL without running it for real" machinery.
Related: #243 (the policy-side analog: validate/fmt tooling + JSON Schema), #406, #400
From WaveHouse-Stats WAVEHOUSE-FEEDBACK.md dogfounding (finding seen 2026-07-01 · dev 029fe1f, doc 7b015bf2); validated by code-read against c816e34 on 2026-07-15.
Area: pipes · admin-api — friction · found via WaveHouse-Stats dogfooding (building the stats page's 14 analytics pipes)
Expected: a way to validate/preview a pipe's SQL — parse + bounded execute (or an
EXPLAIN) as a given role — without publishing it as a live named pipe, mirroring the existingpolicy.validate.Actual:
POST /v1/admin/policy/validatedry-runs a policy (internal/api/router.go:180), but pipes have no counterpart — the admin surface is onlyList/Get/Put/Delete(internal/api/router.go:183-186) plusExecute(:151-152).PUT /v1/admin/pipes/{name}is create-or-update against the live registry, and pipe SQL only ever runs when executed. So the only test loop is: edit the pipe →PUTit live →curlit. A syntactically-bad or pathological pipe is only caught after it is published (it errors rather than crashes, but it is in the registry).Impact: "test" and "publish" are coupled — CI can gate policy files but not pipe SQL. Stats worked around it by standing up a local ClickHouse with a sample
gh_eventstable and validating there first; an adopter without that harness iterates against their live registry. Low severity (pipes are cheap and reversible), but it's a DX gap the product could obviate.Note: a validate path would also give #406's dummy-bind EXPLAIN diagnostic a natural home — same "analyze this pipe's SQL without running it for real" machinery.
Related: #243 (the policy-side analog: validate/fmt tooling + JSON Schema), #406, #400
From WaveHouse-Stats
WAVEHOUSE-FEEDBACK.mddogfounding (finding seen 2026-07-01 · dev029fe1f, doc7b015bf2); validated by code-read againstc816e34on 2026-07-15.