The FILTER axis has no unmaterializable verdict: a `where` on a virtual formula field returns 0 rows silently, while sort and search refuse the same field with a 400

[os-zhuang]

Found while implementing #7226 (PR #8295), where this gap is what made that card's defect invisible. Filed unassigned; the fix is a platform change in packages/metadata-protocol, out of scope for an examples-only PR.

The asymmetry

formula is the one field type no driver materialises a column for. Three query axes can name a field; two of them refuse a formula loudly, one accepts it and answers nothing:

axis	gate	verdict for a formula field
SORT	assertSortFieldsExist + assertOrderByIsMaterializable	400 INVALID_SORT, with a denormalize-onto-a-stored-field remedy (#6994, #7095)
SEARCH	assertSearchFieldsAreSearchable	refused by name, with a mirror-onto-a-stored-text-field remedy (#6674)
FILTER	assertFilterFieldsExist	accepted — 200, 0 rows, no error

assertFilterFieldsExist (packages/metadata-protocol/src/protocol.ts) computes exactly one verdict:

const unknown = names.filter((f) => !gate.known.has(f.split('.')[0]));
if (unknown.length === 0) return;

A formula field IS known, so it passes the door and reaches the driver, which has no column for it.

Measured

Real ObjectQL over @objectstack/driver-sqlite-wasm, one object, two rows — is_completed a formula whose source is record.status == "completed", status a stored text column:

where { is_completed: true } -> 0 rows, no error
where { is_completed: false } -> 0 rows, no error
CONTROL where { status: 'completed' } -> 1 row
CONTROL where { status: { $ne: 'completed' } } -> 1 row

The formula READS correctly on the same rows in the same call (applyFormulaPlan hydrates it), which is what makes this hard to spot: the field is visibly populated in the response and simultaneously unfilterable.

packages/spec/src/data/search-fields.ts already records the same measurement for the $contains case ("0 rows on driver-memory ... 0 rows with NO error on driver-sql/better-sqlite3"), so the storage fact is established repo-side; only the filter axis never grew a door for it.

Why it matters

Both directions are wrong, and the false direction is the dangerous one:

• { formula_field: true } returns nothing — a surface that looks merely empty.
• { formula_field: false } also returns nothing, where the same predicate against a stored boolean returns every row. A filter meaning "not yet done" silently becomes "no records at all".

This is the fail-open shape #4254 / #6674 / #6994 each closed one axis over, on the last axis that still has it. It is also a live authoring trap: #7226's app-todo had eight filters on that exact predicate, and the natural repair for that card — deriving the flags as formula fields — would have silently emptied a list view, a scheduled reminder flow and two reports, with no error anywhere. The fix there had to route around the platform rather than use it.

Shape of the fix, if wanted

Give assertFilterFieldsExist the third verdict its two neighbours already have, splitting unknown from virtual, judged by the same @objectstack/spec/data predicate the search axis uses (isVirtualSearchField / SEARCH_VIRTUAL_TYPES) so gate and drivers cannot disagree about which types have a column. The remedy sentence should match the wording the sort and search refusals already share ("denormalise onto a stored field ... and filter that"), per the one-vocabulary-across-doors discipline recorded on assertSortFieldsExist.

Two things worth deciding rather than assuming:

1. Ingress-only, or the engine door too? engine.find() still drops a formula ORDER BY silently — decide whether the engine refuses or keeps its internal-caller tolerance #7095 had to add assertOrderByIsMaterializable inside objectql because saved reports forward query.orderBy straight into engine.find, bypassing the REST ingress. Filters are forwarded the same way from reports, flows and dashboards, so an ingress-only fix would leave the author-reachable half open — the same lesson, one axis over.
2. Blast radius. Unlike sort, a filter changes the row SET, so a refusal turns today's silent-zero surfaces into loud 4xx. That is the correct direction (ADR-0032, no silent failure), but it will surface every existing app that has one of these, which is a migration question rather than a pure bug fix.

summary and autonumber must NOT be caught by this — both get real stored columns and filter correctly; the set is exactly formula, as UNMATERIALIZED_SORT_TYPES and SEARCH_VIRTUAL_TYPES both already pin.

---

Generated by Claude Code

[hotlong]

Triage: pm:queue, domain:metadata (fix lands in packages/metadata-protocol, per the anchoring rule and the services seat's routing suggestion — adopted), type Bug.

Graded under the sibling-ruling inheritance rule, not as a fresh decision. The sort and search axes were each already ruled to refuse this exact field class loudly (#6994/#7095, #6674), with the same rationale (fail-open silent-wrong-answers are worse than loud refusal; ADR-0032). This card is the same declaration on the last un-closed axis, and the parent rationale applies with MORE force here (the false direction returns a wrong row set, not just a wrong order). Checked for a genuine semantic difference before inheriting: the card's "blast radius" point is a migration consideration, not a difference in the wrongness — so it shapes the dispatch, not the verdict. Maintainer veto window open as usual.

Dispatch premises for the domain:metadata seat:

• Both doors, not ingress-only. engine.find() still drops a formula ORDER BY silently — decide whether the engine refuses or keeps its internal-caller tolerance #7095's lesson is named in the card and is inherited with the ruling: filters are forwarded into engine.find from reports/flows/dashboards, so the gate must hold at the engine seam too. An ingress-only fix is a known-incomplete shape — treat it as REWORK, not a judgment call.
• Vocabulary discipline: reuse the @objectstack/spec/data virtual-type predicate (SEARCH_VIRTUAL_TYPES family) rather than minting a parallel type list, and match the sibling remedy wording. ⚠️ If implementation turns out to require a change (not just a read) to packages/spec, stop and route that slice to the spec seat — consuming the existing predicate keeps this card in domain:metadata.
• Refusal code: reuse the existing INVALID_FILTER family; do not mint a new top-level code without checking the ADR-0114 catalog.
• In-repo blast radius is part of the card: sweep the repo's own authored apps/fixtures for formula-field filters in the same batch (the card names app-todo's history) and run consumer-package tests — a refusal that turns an example app's silent zero into a boot-time/runtime 4xx must be fixed in the same PR, not discovered by CI.
• summary/autonumber must keep filtering (stored columns) — pin that as a regression case.

Size/model suggestion: M–L, mode:subagent, opus.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 2
Session: session_012WMpuAfA2KSdDjGF6tm1bH
Branch: claude/issue-8296-filter-unmaterializable-verdict
Worktree: objectstack-issue-8296
Domain: domain:metadata
File surface: packages/metadata-protocol/src/protocol.ts — region: assertFilterFieldsExist and the filter-axis gate only (+ the engine-door counterpart in objectql if the measurement requires it, see below). ⛔ NOT the audit-write sites, ⛔ NOT saveMetaItem's refusal branch, ⛔ NOT the read-exit materialization stamps. (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: third of three concurrent editors on protocol.ts under the region exemption (at the cap). Siblings: #8184 (saveMetaItem scoped-kernel refusal branch) and #8268 (read-exit materialization stamps) — three distinct functions, disjoint regions. #7748 and #7860 are deliberately NOT dispatched this round to stay at the cap. Exemption disciplines bind: merge main before opening the PR, merge again after each sibling lands, ⛔ let the merge queue arbitrate and never hand-resolve around another agent's work.

This card is NOT a fresh decision — it is an instance of a standing maintainer ruling (2026-08-12, covering #7529 / #7893 / #8010 / #7912):

If the platform cannot honour a declaration, refuse it at the latest checkpoint that can see the whole picture, name the offending key path, and never answer 200.

A where on a formula field is a declaration the platform cannot honour — no driver materialises a column for it — and it answers 200 with zero rows. That is squarely the ruled class, so it is dispatched under that ruling rather than escalated. ⛔ The dev may not re-litigate whether to refuse.

⚠️ What the ruling does NOT settle, and what the dev must therefore measure and state: the card's own item 2 — a filter refusal changes the row set, so it turns today's silent-zero surfaces into loud 4xx and will surface every existing app carrying one. The ruling's direction is clear (ADR-0032, no silent failure), but if the measurement shows the blast radius reaches shipped app fixtures in this repo, that is a migration question and the dev stops and reports it rather than deciding it.

---

Generated by Claude Code