driver-sql: an unresolvable WHERE column on `aggregate()` answers DATABASE_ERROR/500 where `find()` and `count()` answer INVALID_FILTER/400 — the #8790 refusal never reached the third read door

[os-zhuang]

Found while implementing #11455 (the aggregate door's terminal backend-fault envelope). Filed unassigned as an out-of-scope finding — #11455 is fenced to enveloping-only and answering this needs a classifier it did not measure.

What was measured

On claude/issue-11455-bool-aggregate-envelope (i.e. with #11455's envelope in place), against embedded SQLite via the built @objectstack/driver-sql:

find where nosuchcol => code=INVALID_FILTER status=400
 "Filter on 'nosuchcol' names a column that object 'probe_par' has no column for…"
count where nosuchcol => code=INVALID_FILTER status=400 (identical message)
agg where nosuchcol => code=DATABASE_ERROR status=500
 "The database refused to run this query for object 'probe_par'. The driver could
 not attribute the failure to any part of the request…"
agg avg(nosuchcol) => code=DATABASE_ERROR status=500
agg groupBy nosuchcol => code=DATABASE_ERROR status=500

The first two rows are #8790's ruled answer (maintainer, 2026-08-15): one unresolvable WHERE column, one answer, on both read halves, naming the column so the caller can fix it. aggregate() is the third read door and never got the arm — before #11455 it threw the raw dialect error, and after #11455 it answers the generic terminal envelope.

So the exact split #8790 closed is still open one door over: a list view's find()/count() say "'nosuchcol' is not a column of this object" with a 400, while the dashboard tile over the same object answers an opaque 500 for the same predicate.

Why #11455 deliberately did not fix it, and what the fix actually needs

A blanket isUnresolvableColumnError arm on this door would be wrong, which is why it was not added. unresolvableFilterColumnError's words are

Filter on '' names a column that object '' has no column for, so the predicate never ran.

and aggregate() names columns in three clauses, not one: the where (via applyFilters), the groupBy fields, and each aggregation's field. Rows 4 and 5 above show the other two — an author who wrote avg('nosuchcol') or grouped by a missing field would be told their filter was wrong. That is exactly the unsupportable attribution the #8931 ruling («同意 C», 2026-08-17) refuses to make, so #11455 took the honest generic envelope instead.

Closing it properly means deciding which clause the dialect-named column came from. The information is available at the call site without a new dialect predicate — aggregate() already holds the groupBy fields and the aggregation fields while it builds the statement, and unresolvableColumnNameOf already extracts the name from all three dialects' wordings — so the shape is roughly:

• name resolves to a groupBy / aggregation field ⇒ a refusal about that clause (which does not exist yet; INVALID_FIELD and INVALID_QUERY are both catalogued candidates, and picking between them is the decision this card carries);
• name resolves to neither ⇒ the WHERE, so driver-sql: one unresolvable WHERE column, two answers — find() silently returns [] while count() throws a raw dialect error with no ADR-0112 envelope #8790's existing unresolvableFilterColumnRefusal applies verbatim;
• name is null (a wording nothing parsed) ⇒ the driver-sql (PG): sum/avg/min/max over a boolean column throw the raw PostgreSQL 42883 with no ADR-0112 envelope (status undefined) #11455 terminal, unchanged.

⚠️ Note the third arm matters: unresolvableColumnNameOf returning null is a real answer, and reading it as "not an unresolvable column after all" is the regression its own docblock warns about.

Scope note

Independent of #11152 / #11249 (whether a boolean aggregate should answer a number or refuse) — this is about a column that does not exist at all, on any type.

Region: packages/drivers/driver-sql/src/sql-driver.ts, the aggregate() body only.

[os-zhuang]

Triage (Routine seat, hourly round): → pm:queue + domain:engine, type Bug.

Rationale: lands in packages/drivers/driver-sql. aggregate() answering DATABASE_ERROR/500 where find()/count() answer INVALID_FILTER/400 for the same unresolvable column is refusal-parity drift — the #8790 refusal never reached the third read door. Family serial note: part of this round's driver-sql group (#11535 #11541 #11550 #11565 + blocked #11431) — engine seat answers fold-or-serial under the five gates at dispatch.

---

Generated by Claude Code

[huangyiirene]

Claim: PM loop round 2
Session: session_01VK8rFDtg8eREaxBGX99Csn
Branch: claude/issue-11541-aggregate-unresolvable-column-refusal
Worktree: objectstack-issue-11541
Domain: domain:engine
File surface: packages/drivers/driver-sql/src/sql-driver.ts (aggregate() body only) + its test files (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: claude-fable-5
Clause-②: yes — today an unresolvable column on this door answers DATABASE_ERROR/500; after this it answers a 400 with a named code. That is a change to contract reject behaviour on a public API, whatever the file paths say, so it goes at CONTRACT_REVIEW_TIER (claude-fable-5, read at source: scripts/pm/dispatch-gates.mjs:3070). ⛔ No needs:contract-review label is owed — dispatching at the tier discharges the obligation.
Serial constraints cleared, measured on origin/main (file is 14305 lines):

• Target region: aggregate() at 7635, body to ~7830. Supporting symbols it will read but which live outside the body: unresolvableColumnNameOf 666, unresolvableFilterColumnRefusal 7366, backendStatementFault 7416.
• [observation] driver-sql (MySQL): introspectForeignKeys returns a composite key's columns in UNSPECIFIED row order — no ORDER BY ORDINAL_POSITION #11379 (this seat, in flight, same file) is in introspectForeignKeys at 13757+ — ~6000 lines away, different method. Disjoint.
• PR fix(driver-sql): introspectUniqueConstraints reports single-column uniqueness on all three dialects (#11202) #11657 (spec seat, draft, same file) is at 3686 and 14059+. Disjoint.
• driver-sql: single→multi-value field change never migrates the existing column type (varchar/text kept), arrays silently stored as stringified literals — data corruption on Postgres #11535 (this seat, in flight) is in schema-drift.ts — different file.
• H17 on-hold trigger index: the two holds naming this file, drivers(sql): 共享 canonical 修复表达式把「裸数字文本」当儒略日读,backfill 会把这个误读写进盘里(观察项) #6009 (sqliteCanonicalDatetimeSql / backfillCanonicalDatetimes) and drivers(sql): upsert's empty-merge-set fallback is merge-ALL, which re-admits every insert-only column — currently unreachable, but it is the wrong shape for "nothing to merge" #8740 (insertOnlyUpsertColumns / a 4th dialect / conflict-target non-null DEFAULT), declare restart conditions on symbols. aggregate() is none of them ⇒ neither fires, no rider owed.

⚠️ The card calls the code choice "the decision this card carries". I think the repo already decided it — verify, do not take my word

The card frames INVALID_FIELD vs INVALID_QUERY as an open decision. Before dispatching I looked, and the evidence points one way:

• packages/spec/src/api/errors.zod.ts annotates the two catalogue members with their own one-line meanings: INVALID_FIELD — "Invalid field value" (line 55) vs INVALID_QUERY — "Malformed query syntax" (line 63). An unresolvable column name is a name the query asserts and the object does not have; it is not a value that failed validation.
• packages/spec/src/data/aggregation-conformance.ts:43 records the refusal envelope this door already publishes (drivers(sql,turso): Unsupported aggregate function 两面都是裸 Error(code/status 皆 undefined),且三个 spec 已声明的聚合函数无任何 SQL 后端编译 #5907): INVALID_QUERY/400 for an undeclared name, NOT_IMPLEMENTED/501 for a declared-but-uncompiled one. ⚠️ Honest bound on that reading: drivers(sql,turso): Unsupported aggregate function 两面都是裸 Error(code/status 皆 undefined),且三个 spec 已声明的聚合函数无任何 SQL 后端编译 #5907's envelope is about an undeclared function name, not a column — so it is a strong precedent for the spelling, not a decision already made about columns.

⇒ Treated as a PM mechanism assumption, not a ruling: the dev verifies against the catalogue and the existing refusal pins and follows the evidence. If it points at INVALID_FIELD, or if neither fits, that is a fork to report — ⛔ not something to settle by preference.

⛔ Do not register a new error-code catalogue member. ADR-0112 D3/D4 closed that vocabulary, and this lane has two standing precedents for respecting it: #11455 declined to add a code for exactly this door, and #11230 deliberately did not add a second member for a same-shaped refusal. If the analysis genuinely requires a new code, stop and report — that is a maintainer decision, not a dispatch.

What makes this card hard, in one paragraph

The naive fix is wrong and the card says why: a blanket isUnresolvableColumnError arm would tell an author who wrote avg('nosuchcol') that their filter was wrong. aggregate() names columns in three clauses — where, groupBy, and each aggregation's field — so closing this properly means attributing the dialect-named column to the clause it came from. The information is at the call site already (the method holds the groupBy fields and aggregation fields while building the statement) and unresolvableColumnNameOf extracts the name across all three dialects, so no new dialect predicate is needed.

⚠️ The third arm is the one that gets dropped: unresolvableColumnNameOf returning null is a real answer meaning "no dialect wording parsed", and reading it as "not an unresolvable column after all" is the regression its own docblock warns about. The null case must keep #11455's terminal envelope unchanged.

Premise-first

The card's measurements were taken on the #11455 branch before it merged. #11455 has since landed (9d3c04d3). ⛔ Re-measure all five rows on current main before building on them — the envelope the card describes as "after #11455" is now simply the shipped behaviour, and the baseline may read differently.

---

Generated by Claude Code