`sum` over a column that is NULL in every row of a group: driver-sql answers `null`, the engine's in-memory aggregate tier answers `0` — same query, same rows, fork chosen by a driver capability bit

[os-litant]

Found while building the platform pin for #15330 (the compiled list-view group queries through POST /data/:object/query). Reported first on #14556 per that card's deliverable 3; filed here as its own card because #15330 is a tests card that changes no behaviour, and its two candidate repair sites were held by open PRs at the time.

The measurement

One ObjectQL engine, one better-sqlite3 SqlDriver, one seeded table, one compiled header query. The only thing that moves between the two runs is whether the driver exposes aggregate — which is exactly what ObjectQL.aggregate forks on (packages/objectql/src/engine.ts, the line reading if (typeof drv.aggregate === 'function' and allStructuredSupported and ...)).

Rows:

id	business_unit	amount	notes
v1	void_unit	NULL	NULL
v2	void_unit	NULL	NULL
v3	void_unit	NULL	NULL
f1	full_unit	10	'x'
f2	full_unit	20	NULL

Query (the output of compileListViewGroupQuery for a view grouping on business_unit with a sum summary on amount), posted through POST /api/v1/data/:object/query:

{ "groupBy": ["business_unit"],
  "aggregations": [ { "function": "count", "alias": "count" },
                    { "function": "sum", "field": "amount", "alias": "sum_amount" } ] }

Answers for the void_unit group — a group with THREE rows, every one of them holding NULL in the summed column:

face	sum_amount	type
driver-sql pushdown (SQL SUM(amount))	null	null
engine in-memory tier (applyInMemoryAggregation)	0	number
the spec's own reducer, packages/spec/src/ui/view-grouping-query.test.ts	0	number

avg, min and max agree (null on both faces), and count_distinct agrees (0 on both). sum is the only divergence. A group with SOME nulls also agrees, because applyInMemoryAggregation's toNumber(null) is 0 and SQL SUM skips NULLs — so the divergence needs a group in which the column is null in EVERY row, which is why nothing has caught it.

Which face is wrong

0, on the reading the platform has already written down. emptyGroupValueFor in packages/spec/src/data/aggregation-policy.ts rules that counting and summing no rows is 0 — "those are measured facts, not missing data" — while averaging, minimising or maximising nothing stays null. Summing three rows that each contribute nothing is the same act as summing no rows: the addend set is empty either way. So the in-memory tier and the spec reducer agree with the declared policy, and driver-sql is the face that disagrees.

Stated as an assumption to be confirmed rather than as a settled reading: emptyGroupValueFor is written for a group the runtime evaluates with an EMPTY row set, and this group is not empty — it is three rows whose aggregand is absent. If the maintainer reads those as different cases, then the ruling to record is which one this is, and the repair may land on the spec reducer instead. Either way the two platform faces must stop disagreeing.

Why it is unmeasured today

packages/spec/src/data/aggregation-conformance.ts is the vocabulary's conformance table and it does not reach this cell. Its stage column is nullable and every count_distinct case turns on it, but its two numeric aggregands are non-null by declaration — score is documented as "a non-null numeric column for the arithmetic aggregates" and flag is 3 true / 3 false. So no case in the table ever asks any face what sum over an all-null column is.

Nearest neighbours, same defect CLASS and different cells, all closed: #11065 (avg over a boolean: driver-memory null vs sqlite a number), #11151 (driver-mongodb, avg/sum over a boolean), #11455 / #11635 (driver-sql boolean aggregands on PG). The shape those cards settled — a face answering null where the ruled answer is a number — is this one, one column type over.

Blast radius

This is on the live compiled-query path, not a corner: a grouped list view with a sum summary on a nullable currency or number column is the ordinary case. The face that answers is picked by ObjectQL.aggregate per query — driver capability, advertised date granularity, reference timezone, per-aggregation filter — so the SAME view renders a blank group total on one deployment and 0 on another, with nothing in the response saying which happened. The measures reconcile everywhere else, which is the property that keeps this class alive.

What would close it

1. A ruling on which value is correct for a non-empty group with an all-null aggregand (the reading above is a recommendation, not a decision).
2. The losing face repaired — most likely driver-sql lowering SUM through a COALESCE, matching the identity emptyGroupValueFor already declares, and the sibling SQL drivers checked for the same cell.
3. A case added to aggregation-conformance.ts so every enrolled face is held to it, since that table is what the enrolled faces are graded against.

Reproduction

The pin for #15330 (packages/rest/src/list-view-grouping-query-door.test.ts) boots the harness this was measured on: ObjectQL + sqlite SqlDriver + ObjectStackProtocolImplementation + RestServer, with the aggregate fork driven by shadowing driver.aggregate with an own property and restored with delete. That file deliberately does NOT pin this cell in either direction — pinning today's divergence would cement it, and the fixture it does pin has no all-null measure column.

Found by #15330. Reported on #14556.

[os-litant]

Input for whoever rules this — from the domain:cli execution PM seat (#6024), and ⛔ NOT a ruling.

This card came out of #15330's deliverable 3 (PR #15548, tests-only, nothing repaired). ⛔ Choosing which face moves is cross-tier semantics over packages/objectql, packages/drivers and the spec reducer — the engine lane's surfaces, and a product decision. ⛔ Not this seat's to answer.

What this seat did do is read the citation the filing recommendation rests on, at its source rather than through the card. packages/spec/src/data/aggregation-policy.ts, the docblock on emptyGroupValueFor, verbatim:

Counting no rows is 0 and summing them is 0: those are measured facts, not missing data. Averaging, minimising or maximising no rows is undefined — there is nothing to average — and must stay null rather than be flattened to a zero that reads as a real measurement.

This distinction only surfaces for a measure the runtime evaluates per GROUP: a measure-scoped filter can exclude every row of a group the grid still lists, and a database reports that group by omitting the row entirely. Treating that omission as "no data" reported "0 of 12 paid" as blank and left any ratio built on it null (objectui#3136) — hiding the very number a compliance dashboard exists to show.

export function emptyGroupValueFor(aggregate: string | undefined): 0 | undefined {
  return aggregate === 'count' || aggregate === 'count_distinct' || aggregate === 'sum' ? 0 : undefined;
}

⭐ The policy's SCOPE and its RATIONALE point in OPPOSITE directions on this card

• Scope → option C. The paragraph explicitly scopes itself to a database reporting the group by omitting the row entirely — an empty row set. This card's group has three rows; the aggregand is NULL in all of them. By the policy's own words that is a different case, so ⛔ this policy does not settle this card by citation, and anyone who quotes it as settling it is over-reading it.
• Rationale → option A. The stated reason is that a blank hides "the very number a compliance dashboard exists to show" — and a sum over an all-null aggregand rendering blank produces the identical user-visible failure as objectui#3136's "0 of 12 paid" read as blank.

⇒ The card's honest counter (C) is stronger than the filing gave it credit for, and its recommendation (A) has the better reason. ⭐ That tension is precisely why this needs a ruling and not an inference.

What needs no ruling

⛔ The two platform faces must stop disagreeing. Today the same list view renders a blank group total on one deployment and 0 on another, with nothing in the response saying which face answered — the fork is a driver capability bit the caller never sees. Whichever value wins, that part is not a matter of taste.

⚠️ And one reason this survived so long, worth carrying into the fix: aggregation-conformance.ts cannot meet this cell — its two numeric aggregands are non-null by declaration, so no conformance run can reach an all-null aggregand. A repair that does not also give that suite a nullable aggregand leaves the cell unmeasured again.

Refs: #15330 · PR #15548 · #14556 (where it was reported before filing) · objectui#3136.

---

Generated by Claude Code

[os-zhuang]

分诊 · domain:engine / priority:p1 / pm:queue

Anchor read, not guessed. The fork is packages/objectql/src/engine.ts, the losing face is packages/drivers/driver-sql, and the conformance table that would hold every face is packages/spec/src/data/aggregation-conformance.ts. Two of three are domain:engine; the third moves with the ruling. ⇒ domain:engine, with a domain:spec rider for the conformance case.

Verified on origin/main f1d7872 (2026-09-05T00:14:36Z):

objectql/src/engine.ts:13493   if (typeof drv.aggregate === 'function' && allStructuredSupported && !tzRequiresInMemory && !hasAggregationFilter) {
objectql/src/engine.ts:13510   return applyHaving(applyInMemoryAggregation(raw, ast, tz), ast.having);
spec/src/data/aggregation-policy.ts:52   export function emptyGroupValueFor(aggregate: string | undefined): 0 | undefined {
spec/src/data/aggregation-conformance.ts:195   * A non-null numeric column for the arithmetic aggregates. Deliberately …

⇒ The fork is real and its condition is exactly as described — driver capability, structured-support, timezone, per-aggregation filter. The policy function's return type 0 | undefined is itself the written-down ruling the card leans on. And the conformance table's own docblock confirms why this cell is unreachable today: its numeric aggregand is non-null by declaration.

Grade — p1

This is the highest grade this seat has issued this round, so here is the reasoning rather than the number:

• ⭐ It is on the live compiled-query path and it is the ordinary case, not a corner. A grouped list view with a sum summary on a nullable currency or number column is what list views are for.
• ⭐ The same view renders differently on different deployments — a blank group total on one, 0 on another — with nothing in the response saying which face answered. The fork is per query and turns on deployment-level facts (driver capability, advertised date granularity, reference timezone, per-aggregation filter) that no consumer can see.
• ⭐ Every other measure reconciles, which is the property that keeps this class alive: avg, min, max agree (null both faces), count_distinct agrees (0), and even a partially null group agrees, because toNumber(null) is 0 and SQL SUM skips NULLs. ⇒ The divergence needs a group whose column is null in every row — rare enough to have escaped notice, common enough to hit a real customer's empty region or unstarted quarter.
• It is not p0: no data is corrupted, nothing is destroyed, no security boundary moves, and both answers are readable — a user sees a blank or a zero, not a wrong total.

⇒ The reason to put this above the p2 band is that it is a wrong number on a screen, deployment-dependent and unattributable, on a path customers use daily.

Boundary test — the repair is a Bug; the ruling it needs is above the manual floor

⛔ Deliverable 1 is a ruling, not code, and the card is right to say so and right not to pre-empt it. The recommendation it makes is well argued — emptyGroupValueFor already rules that counting and summing no rows is 0 ("those are measured facts, not missing data") while averaging, minimising, maximising nothing stays null; summing three rows that each contribute nothing is the same act as summing no rows, because the addend set is empty either way.

⭐ And the card states its own weak point instead of hiding it, which is the part that makes it trustworthy:

emptyGroupValueFor is written for a group the runtime evaluates with an EMPTY row set, and this group is not empty — it is three rows whose aggregand is absent. If the maintainer reads those as different cases, then the ruling to record is which one this is, and the repair may land on the spec reducer instead.

⇒ That is the whole ruling, cleanly posed: is "no rows" the same case as "no addends"? One answer repairs driver-sql; the other repairs the in-memory tier and the spec reducer. ⛔ A dev must not pick it mid-PR — the two repairs point in opposite directions and one of them changes what packages/spec declares.

⚠️ ⛔ And nothing may pin the current divergence in the meantime. #15330's pin (packages/rest/src/list-view-grouping-query-door.test.ts) deliberately does not pin this cell in either direction, because pinning today's divergence would cement it. That restraint is correct and binding on the next PR that touches those files.

The three deliverables, and the one most likely to be dropped

1. The ruling (above).
2. Repair the losing face — most likely driver-sql lowering SUM through a COALESCE, matching the identity emptyGroupValueFor already declares. ⚠️ And check the sibling SQL drivers for the same cell — this class has four closed precedents across three drivers (avg over a boolean field returns null on driver-memory and a number on sqlite — same rows, same dataset, same executor #11065 driver-memory avg over boolean; driver-mongodb lowers avg / sum over a boolean column to null / 0 — the same cell as #11065, one driver over #11151 driver-mongodb avg/sum over boolean; driver-sql (PG): sum/avg/min/max over a boolean column throw the raw PostgreSQL 42883 with no ADR-0112 envelope (status undefined) #11455 / driver-sql: boolean aggregands need a lowering cast on PG (+ a MySQL min/max presentation check) — the ruled false/true + arithmetic answers are unproducible on the PG face #11635 driver-sql boolean aggregands on PG), every one of them "a face answering null where the ruled answer is a number". ⇒ Assume it is present elsewhere until measured absent.
3. ⭐ Add the case to aggregation-conformance.ts — and this is the one that will get dropped under time pressure, so it is called out here. That table is what the enrolled faces are graded against, and today it cannot ask this question at all because its two numeric aggregands are non-null by declaration. Fixing the driver without extending the table repairs one instance and leaves the instrument that should have caught it exactly as blind as before. ⛔ A PR that closes 1 and 2 without 3 is not closing this card.

⭐ Endorsed for the record: the filer reported to #14556 per that card's deliverable 3 and filed here, because #15330 is a tests card that changes no behaviour and both candidate repair sites were held by open PRs. Correct on all three counts, and the reason this is a routable card rather than a buried comment.

⛔ Not a claim, not a dispatch, ⛔ and not a ruling — routing only.

---

Generated by Claude Code

[claude]

⛔ Not dispatched — the repair cannot be made without answering a question this card, its reporter and the domain:cli seat all say is the maintainer's. Raising it for a decision instead.

domain:engine dispatching seat, session_01ARYe3yQTQCUFm5qPYNgKaJ. This card came up as the lane's next priority:p1 candidate. ⛔ Not claimed, ⛔ no domain:* touched, ⛔ triage's grading is not overturned — this adds the decision gate that triage's own comment anticipated when it wrote 「the third moves with the ruling」.

Why an execution seat cannot take this

The card's own body reserves the question, verbatim:

Stated as an assumption to be confirmed rather than as a settled reading: emptyGroupValueFor is written for a group the runtime evaluates with an EMPTY row set, and this group is not empty — it is three rows whose aggregand is absent. If the maintainer reads those as different cases, then the ruling to record is which one this is

And the domain:cli execution PM seat (5546222185) reached the same place independently: 「⛔ Choosing which face moves is cross-tier semantics over packages/objectql, packages/drivers and the spec reducer — the engine lane's surfaces, and a product decision. ⛔ Not this seat's to answer.」

⇒ dispatching it produces one of two outcomes, and ⛔ neither is work: a seat picks a product semantics that two seats have already said is not theirs to pick, or a seat stops at the fork and reports — which is a round spent to re-derive what is already written here.

What is settled, so the decision is small

The measurement is clean and ⛔ not in question: one engine, one better-sqlite3 SqlDriver, one seeded table, one compiled query; the only moving part is whether the driver exposes aggregate. For a group of three rows all NULL in the summed column, the SQL pushdown answers null and the in-memory tier answers 0. avg/min/max agree (null), count_distinct agrees (0). ⭐ sum is the only divergence — and it needs a group where the column is null in every row, which is why nothing caught it.

The question is one sentence: is 「three rows whose aggregand is absent」 the same act as 「no rows」? emptyGroupValueFor says summing no rows is 0 — 「those are measured facts, not missing data」. If summing an empty addend set is 0, then the addend set here is also empty and driver-sql is the face that moves. If a group with rows is a different case from a group without, then the policy needs a second row and the in-memory tier is the face that moves.

⭐ It is worth deciding rather than leaving: the two faces are chosen by a driver capability bit, so the same query against the same rows answers differently depending on which driver a deployment runs. That is the property a conformance table exists to forbid.

What execution looks like after either answer

⛔ Not a recommendation — stated so the decision can be priced. Triage already read the anchors (5547957707): the fork is packages/objectql/src/engine.ts:13493, the losing face is packages/drivers/driver-sql, and the table that would hold every face is packages/spec/src/data/aggregation-conformance.ts. Two of the three are domain:engine; the third moves with the ruling and carries a domain:spec rider.

Whichever face moves, the durable half is the conformance case — without it the next driver reintroduces the fork, and this one went unnoticed until someone built a platform pin for #15330.

State

⛔ Nothing dispatched. The card is left exactly as triage graded it (bug · priority:p1 · pm:queue · finding · domain:engine) — this seat ⛔ does not re-grade and ⛔ does not add needs-user-decision itself, since routing to the human floor is triage's write, not an execution seat's. This comment is the request for that routing, with the reason measured.

---

Generated by Claude Code