Summary
Two related rough edges in the WH_PIPES_DIR file-bootstrap path for named pipes.
1. Bootstrapped pipes are stuck admin-only. A .sql file loaded from WH_PIPES_DIR becomes a pipe with empty allowed_roles → admin-only (internal/pipes/pipes.go: "empty = admin role only (fails closed)"), and the file can't declare allowed_roles or parameter definitions. So a file-bootstrapped public pipe can't actually be reached by a non-admin role — you must re-register it via PUT /v1/admin/pipes/{name} with roles+params. In practice WH_PIPES_DIR is only usable for admin-only, param-less pipes.
2. Inline empty default {{name:}} is treated as REQUIRED (bug). A pipe body with ... {{division:}} ... rejects a call that omits division (HTTP 400 "missing required param") instead of defaulting to empty string. Given {{name:default}} semantics, {{name:}} reads as "default = empty string", not "required". (e.g. scoreboard_public?day=1 400s because division has an empty inline default.)
Impact
WH_PIPES_DIR looks like a convenient GitOps way to ship a pipe library, but every pipe then needs a follow-up admin-API call to set roles + dodge the empty-default trap — so the bootstrap is effectively unusable for the common case (public pipes with optional params).
Suggested
- Let the file-bootstrap declare
allowed_roles + param defs — e.g. a sidecar <name>.json/.yaml, SQL frontmatter, or a pipes.manifest.json the loader reads.
- Treat
{{name:}} as an empty-string default, not a required param.
(Related to the tracked "bring named pipes under the main access-control policy" work. Found building the SCC 2026 tracker pilot; we ship a pipes.manifest.json + register via the admin API to work around both.)
Summary
Two related rough edges in the
WH_PIPES_DIRfile-bootstrap path for named pipes.1. Bootstrapped pipes are stuck admin-only. A
.sqlfile loaded fromWH_PIPES_DIRbecomes a pipe with emptyallowed_roles→ admin-only (internal/pipes/pipes.go: "empty = admin role only (fails closed)"), and the file can't declareallowed_rolesor parameter definitions. So a file-bootstrapped public pipe can't actually be reached by a non-admin role — you must re-register it viaPUT /v1/admin/pipes/{name}with roles+params. In practiceWH_PIPES_DIRis only usable for admin-only, param-less pipes.2. Inline empty default
{{name:}}is treated as REQUIRED (bug). A pipe body with... {{division:}} ...rejects a call that omitsdivision(HTTP 400 "missing required param") instead of defaulting to empty string. Given{{name:default}}semantics,{{name:}}reads as "default = empty string", not "required". (e.g.scoreboard_public?day=1400s becausedivisionhas an empty inline default.)Impact
WH_PIPES_DIRlooks like a convenient GitOps way to ship a pipe library, but every pipe then needs a follow-up admin-API call to set roles + dodge the empty-default trap — so the bootstrap is effectively unusable for the common case (public pipes with optional params).Suggested
allowed_roles+ param defs — e.g. a sidecar<name>.json/.yaml, SQL frontmatter, or apipes.manifest.jsonthe loader reads.{{name:}}as an empty-string default, not a required param.(Related to the tracked "bring named pipes under the main access-control policy" work. Found building the SCC 2026 tracker pilot; we ship a
pipes.manifest.json+ register via the admin API to work around both.)