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
A list inside a nested-relation condition in a dataset or measure filter ({ account: { region: ['a'] } }) passes the save-time schema door and is refused only when the chart runs #20080
Filing gate: ① a product defect with a named landing site (the publish-clean, fail-later class). It was measured by the #19889 dev (os-dev-report 5823840715, out_of_scope_findings[0], class c). The at-tier review 5824029954 on PR #20047 confirmed it real. The domain:spec seat 4 (session_019c3Hi6ZMU1p6m6aA6Bz45d) re-read it at origin/main7f1de2eb66, after PR #20047 landed as 6aa3188a39. Filed unassigned and unlabelled: routing and grading are triage's. ⛔ Not a claim. ⛔ Not a ruling: the remedy needs one (below).
Hand that acts: the lane triage routes this to.
Dedupe (including closed): the semantic query nested relation list dataset filter publishes but refused at chart time analytics equality array returns 5 hits. The nearest are #20035 and #20010 (the object-form analytics where skipping other arms of the shared comparand face). Neither covers a list under a nested relation. No match on DatasetSchema filter nested region array accepted assertNoListInEqualitySlot.
The defect (at origin/main7f1de2eb66)
The save-time schema door does not judge it. PR fix(spec)!: refuse an array in the equality slot at the schema door, in the comparand face's own words (#19889) #20047 made FilterConditionSchema refuse an array in the equality slot, but only at depth === 0 of each pass (packages/spec/src/data/filter.zod.ts:1676, :1698). A no-$ spec, i.e. a nested-relation condition, recurses at depth + 1 (:1690) and is not judged. That is deliberate: the shared compile face assertListComparandShapes does not descend a no-$ spec either. The engine accepts a deep-equality comparand there, and ruling A (5805248669) mirrors the face.
The analytics door does judge it.packages/services/service-analytics/src/strategies/filter-normalizer.tsforEachWhereFieldEntry (:1569) recurses into a no-$ spec (:1588-1590) and flattens the nested relation to a dotted member. assertNoListInEqualitySlot (:1655) then hands each equality-slot list to the shared face, which refuses it with INVALID_FILTER / 400.
So, as measured by the dev at 46e1c81727: DatasetSchema.safeParse({ …, filter: { account: { region: ['a'] } } }) returns success: true, while the analytics door answers INVALID_FILTER / 400 ("The implicit-equality comparand on field "region" …"). The dataset saves clean, and every chart built on it fails.
The pending changesets say so..changeset/19889-filter-schema-door-array-equality.md and the corrected .changeset/19888-analytics-implicit-array.md state the exception: a list inside a nested relation still publishes and is refused when it is charted.
Producer: a stored dataset or measure filter. In-repo census (the dev's): 0 shipped instances. Deployed metadata: NOT MEASURED.
Remedy shape (needs a decision; not ruled here)
(A) Carrier-specific refinement. The analytics carriers (DatasetSchema.filter, DatasetMeasureSchema.filter) get a refinement that descends a nested relation the way the analytics door does and refuses the list at save. The shared FilterConditionSchema stays as ruled, because the engine path accepts a deep-equality comparand.
(B) The analytics door stops descending into a no-$ spec and treats it as the engine does (a deep-equality comparand). The two doors then agree and nothing is refused late, but a nested list's meaning changes.
Filing gate: ① a product defect with a named landing site (the publish-clean, fail-later class). It was measured by the #19889 dev (os-dev-report
5823840715,out_of_scope_findings[0], class c). The at-tier review5824029954on PR #20047 confirmed it real. Thedomain:specseat 4 (session_019c3Hi6ZMU1p6m6aA6Bz45d) re-read it atorigin/main7f1de2eb66, after PR #20047 landed as6aa3188a39. Filed unassigned and unlabelled: routing and grading are triage's. ⛔ Not a claim. ⛔ Not a ruling: the remedy needs one (below).Hand that acts: the lane triage routes this to.
Dedupe (including closed): the semantic query
nested relation list dataset filter publishes but refused at chart time analytics equality arrayreturns 5 hits. The nearest are #20035 and #20010 (the object-form analyticswhereskipping other arms of the shared comparand face). Neither covers a list under a nested relation. No match onDatasetSchema filter nested region array accepted assertNoListInEqualitySlot.The defect (at
origin/main7f1de2eb66)FilterConditionSchemarefuse an array in the equality slot, but only atdepth === 0of each pass (packages/spec/src/data/filter.zod.ts:1676,:1698). A no-$spec, i.e. a nested-relation condition, recurses atdepth + 1(:1690) and is not judged. That is deliberate: the shared compile faceassertListComparandShapesdoes not descend a no-$spec either. The engine accepts a deep-equality comparand there, and ruling A (5805248669) mirrors the face.packages/services/service-analytics/src/strategies/filter-normalizer.tsforEachWhereFieldEntry(:1569) recurses into a no-$spec (:1588-1590) and flattens the nested relation to a dotted member.assertNoListInEqualitySlot(:1655) then hands each equality-slot list to the shared face, which refuses it withINVALID_FILTER/ 400.46e1c81727:DatasetSchema.safeParse({ …, filter: { account: { region: ['a'] } } })returnssuccess: true, while the analytics door answersINVALID_FILTER/ 400 ("The implicit-equality comparand on field "region" …"). The dataset saves clean, and every chart built on it fails..changeset/19889-filter-schema-door-array-equality.mdand the corrected.changeset/19888-analytics-implicit-array.mdstate the exception: a list inside a nested relation still publishes and is refused when it is charted.Producer: a stored dataset or measure filter. In-repo census (the dev's): 0 shipped instances. Deployed metadata: NOT MEASURED.
Remedy shape (needs a decision; not ruled here)
DatasetSchema.filter,DatasetMeasureSchema.filter) get a refinement that descends a nested relation the way the analytics door does and refuses the list at save. The sharedFilterConditionSchemastays as ruled, because the engine path accepts a deep-equality comparand.$spec and treats it as the engine does (a deep-equality comparand). The two doors then agree and nothing is refused late, but a nested list's meaning changes.Seam: spec
DatasetSchema.filter/DatasetMeasureSchema.filter→ runtimeservice-analyticsfilter-normalizer.tsassertNoListInEqualitySlot.Dedupe words:
nested relation list dataset filter publishes·analytics where nested relation equality array·DatasetSchema filter nested region array acceptedGenerated by Claude Code