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
[finding] service-analytics is a second filter emitter that still refuses $field — a CEL rule that now pushes down on the drivers still 400s through the analytics faces #7604
Reported by the dev seat while implementing #5222 (PR #7582), filed by the spec-lane PM as its own card per that PR's scope boundary. Recording, not claiming.
The residue
#5222 landed cross-field push-down ({ $field: 'col' } → a real column reference) in driver-sql, closing the split where one CEL permission/RLS rule behaved differently depending on whether the query reached a database. service-analytics has its own independent filter emitters — read-scope-sql and filter-normalizer — each carrying its own mirrored comparand gate, and both still refuse $field.
So the split is narrowed, not closed: a CEL rule containing a field-to-field comparison now works through the ObjectQL/driver path and still answers 400 when lowered through the analytics faces.
That issue's maintainer rulings (2026-08-06) are about the driver: same-table columns only, declared-only enumeration, tenant-isolation column forbidden as a referent, federated tables refused. Nothing in them speaks to the analytics emitters, and #5222's dev seat declined to widen a security-relevant acceptance surface in a second subsystem as a side effect — the right call.
Note the envelope difference already recorded in #5222's blast-radius sweep: read-scope-sql refuses with READ_SCOPE_COMPILE_FAILED / 500 rather than INVALID_FILTER / 400, deliberately, because it is compiling an RLS read scope. Any disposition here has to say what that path should do — a 500 on a rule the drivers now execute is a worse split than the 400.
What a card here would have to decide
Do the analytics emitters implement $field under the same four constraints [spec] SqlDriver 将 $field 编译为列对列比较(cross-field comparison push-down) #5222 adopted (same-table, declared-only, tenant column forbidden, federated refused), or do they stay refusing by design because an analytics read scope is a different trust boundary?
If they implement: is the constraint set shareable, or does each emitter re-derive it? [spec] SqlDriver 将 $field 编译为列对列比较(cross-field comparison push-down) #5222 deliberately kept its corpus out of packages/spec/src/data so it would not enrol every driver in conformance DEBT — the same reasoning needs re-running for a second consumer.
If they keep refusing: READ_SCOPE_COMPILE_FAILED / 500 should probably become a loud, documented refusal rather than a compile failure, so the rule author learns the rule is unsupported here instead of seeing a server error.
Natural lane: domain:spec for the acceptance decision (precedent: #5222 itself, #7464). Reference implementation and the constraint arguments: PR #7582.
Reported by the dev seat while implementing #5222 (PR #7582), filed by the spec-lane PM as its own card per that PR's scope boundary. Recording, not claiming.
The residue
#5222 landed cross-field push-down (
{ $field: 'col' }→ a real column reference) indriver-sql, closing the split where one CEL permission/RLS rule behaved differently depending on whether the query reached a database.service-analyticshas its own independent filter emitters —read-scope-sqlandfilter-normalizer— each carrying its own mirrored comparand gate, and both still refuse$field.So the split is narrowed, not closed: a CEL rule containing a field-to-field comparison now works through the ObjectQL/driver path and still answers 400 when lowered through the analytics faces.
Why it was correctly left out of #5222
That issue's maintainer rulings (2026-08-06) are about the driver: same-table columns only, declared-only enumeration, tenant-isolation column forbidden as a referent, federated tables refused. Nothing in them speaks to the analytics emitters, and #5222's dev seat declined to widen a security-relevant acceptance surface in a second subsystem as a side effect — the right call.
Note the envelope difference already recorded in #5222's blast-radius sweep:
read-scope-sqlrefuses withREAD_SCOPE_COMPILE_FAILED/ 500 rather thanINVALID_FILTER/ 400, deliberately, because it is compiling an RLS read scope. Any disposition here has to say what that path should do — a 500 on a rule the drivers now execute is a worse split than the 400.What a card here would have to decide
$fieldunder the same four constraints [spec] SqlDriver 将$field编译为列对列比较(cross-field comparison push-down) #5222 adopted (same-table, declared-only, tenant column forbidden, federated refused), or do they stay refusing by design because an analytics read scope is a different trust boundary?$field编译为列对列比较(cross-field comparison push-down) #5222 deliberately kept its corpus out ofpackages/spec/src/dataso it would not enrol every driver in conformance DEBT — the same reasoning needs re-running for a second consumer.READ_SCOPE_COMPILE_FAILED/ 500 should probably become a loud, documented refusal rather than a compile failure, so the rule author learns the rule is unsupported here instead of seeing a server error.Natural lane:
domain:specfor the acceptance decision (precedent: #5222 itself, #7464). Reference implementation and the constraint arguments: PR #7582.Refs: #5222, #5041, PR #7582, ADR-0015, ADR-0112.