Observation-class finding, filed unassigned with no pm:queue — for triage to grade and route. Raised by the dev on #7598 / PR #7916 as "one place the ruling is slightly awkward, stated rather than papered over", and graded by the services PM as not a blocker for that PR (reasoning below). Carries a second, smaller observation from the same report.
Observation 1 — the attribution seam
The 2026-08-12 maintainer ruling on #7598 (Q1 = B) has NativeSQLStrategy.canHandle decline a query whose where or read scope carries { $field: … }, so it routes to the ObjectQL/engine path and the driver enforces the four #5222 rulings with metadata it owns. That is working as ruled.
The consequence: a read scope carrying a reference the driver refuses — an undeclared column, or the tenant-isolation column — now surfaces as INVALID_FILTER / 400 from the driver, where before the ruling the analytics path answered READ_SCOPE_COMPILE_FAILED / 500 with a withheld message. The refusal moved to the driver along with the compilation.
Why this is not a violation of Q2 = A. Q2 = A governs read-scope-sql's own envelope, and PR #7916 leaves it untouched: same code, same status, same withheld message, and the "Deliberately NOT a 4xx of any flavour, including a 422" module-header paragraph is not rewritten. Verified on the diff. The 400 comes from a different component that the ruling deliberately routed to.
Why it is still worth recording. #5367's adjudication rests on an attribution argument — a caller must not be billed a 4xx for a document they cannot author, and policy field names must not be echoed to the tenant. On this one path, the ruling's routing produces exactly the 4xx that argument was written to prevent. Two independent decisions, each correct on its own terms, meeting at a seam neither anticipated.
Open question for whoever grades this: does the driver's INVALID_FILTER on a read-scope-originated filter need the same withhold treatment #5367 gave the analytics path — and if so, does that belong at the driver, or at the boundary that hands a read scope to it? Note the driver cannot currently distinguish "this filter came from an author's query" from "this filter came from a read scope the caller never saw", which is likely the crux.
⚠️ This may deserve needs-user-decision rather than a dispatch: it is a consequence of a ruling the maintainer made hours ago, and re-deciding it is not a dev-seat or PM-seat call. Filed as finding so triage grades it; the services seat is not pre-empting that.
Observation 2 — an unreachable-today configuration, named rather than hidden
The decline creates one configuration that could not previously occur: a host advertising nativeSql without an aggregate bridge now reaches resolveStrategy's dead end for a $field filter (native declines, and there is nothing to fall back to).
Measured on PR #7916: not reachable from AnalyticsServicePlugin, whose defaults derive both capability flags from the bridges it actually wired. Only a hand-overridden queryCapabilities can construct it. The PR adds a diagnostic for it anyway, with a narrowness control. Recorded here so the reasoning survives the session; no action is claimed to be needed today.
Explicitly NOT claimed
Evidence
Measured 2026-08-12 by the dev on PR #7916 (packages/services/service-analytics, head 94c5580). Full measurement in the <!-- os-dev-report --> comment on #7598 (comment 5262307982); the PM's acceptance reasoning is in comment 5262400038.
Source
Split out of #7598 (PR #7916) — the dev's named residuals, deliberately not decided inside that card.
Refs: #5367 (the withhold adjudication), #5222 (the four cross-field rulings), #7596, #7597.
Observation-class finding, filed unassigned with no
pm:queue— for triage to grade and route. Raised by the dev on #7598 / PR #7916 as "one place the ruling is slightly awkward, stated rather than papered over", and graded by the services PM as not a blocker for that PR (reasoning below). Carries a second, smaller observation from the same report.Observation 1 — the attribution seam
The 2026-08-12 maintainer ruling on #7598 (Q1 = B) has
NativeSQLStrategy.canHandledecline a query whosewhereor read scope carries{ $field: … }, so it routes to the ObjectQL/engine path and the driver enforces the four #5222 rulings with metadata it owns. That is working as ruled.The consequence: a read scope carrying a reference the driver refuses — an undeclared column, or the tenant-isolation column — now surfaces as
INVALID_FILTER/ 400 from the driver, where before the ruling the analytics path answeredREAD_SCOPE_COMPILE_FAILED/ 500 with a withheld message. The refusal moved to the driver along with the compilation.Why this is not a violation of Q2 = A. Q2 = A governs
read-scope-sql's own envelope, and PR #7916 leaves it untouched: same code, same status, same withheld message, and the"Deliberately NOT a 4xx of any flavour, including a 422"module-header paragraph is not rewritten. Verified on the diff. The 400 comes from a different component that the ruling deliberately routed to.Why it is still worth recording. #5367's adjudication rests on an attribution argument — a caller must not be billed a 4xx for a document they cannot author, and policy field names must not be echoed to the tenant. On this one path, the ruling's routing produces exactly the 4xx that argument was written to prevent. Two independent decisions, each correct on its own terms, meeting at a seam neither anticipated.
Open question for whoever grades this: does the driver's
INVALID_FILTERon a read-scope-originated filter need the same withhold treatment #5367 gave the analytics path — and if so, does that belong at the driver, or at the boundary that hands a read scope to it? Note the driver cannot currently distinguish "this filter came from an author's query" from "this filter came from a read scope the caller never saw", which is likely the crux.needs-user-decisionrather than a dispatch: it is a consequence of a ruling the maintainer made hours ago, and re-deciding it is not a dev-seat or PM-seat call. Filed asfindingso triage grades it; the services seat is not pre-empting that.Observation 2 — an unreachable-today configuration, named rather than hidden
The decline creates one configuration that could not previously occur: a host advertising
nativeSqlwithout an aggregate bridge now reachesresolveStrategy's dead end for a$fieldfilter (native declines, and there is nothing to fall back to).Measured on PR #7916: not reachable from
AnalyticsServicePlugin, whose defaults derive both capability flags from the bridges it actually wired. Only a hand-overriddenqueryCapabilitiescan construct it. The PR adds a diagnostic for it anyway, with a narrowness control. Recorded here so the reasoning survives the session; no action is claimed to be needed today.Explicitly NOT claimed
$fieldRLS rule by declining native SQL (#7598) #7916's 26 CI checks are green, including the#5367end-to-end pinanalytics-query-read-scope-withhold.test.tsinruntime(2096/2096). The withhold behaviour on the path analytics dataset 路由的 message 正则兜底没有退休时间表:六族拒收仍靠措辞分类,改一个字就换一个 HTTP 码 #5367 actually adjudicated is intact.Evidence
Measured 2026-08-12 by the dev on PR #7916 (
packages/services/service-analytics, head94c5580). Full measurement in the<!-- os-dev-report -->comment on #7598 (comment 5262307982); the PM's acceptance reasoning is in comment 5262400038.Source
Split out of #7598 (PR #7916) — the dev's named residuals, deliberately not decided inside that card.
Refs: #5367 (the withhold adjudication), #5222 (the four cross-field rulings), #7596, #7597.