Skip to content

docs(changeset): annotate #8296's changeset as breaking#8606

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
os-zhuang merged 1 commit into from
Aug 14, 2026
Merged

docs(changeset): annotate #8296's changeset as breaking #8606

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions .changeset/filter-formula-field-refusal.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -5,6 +5,16 @@

fix(filter): a `where` on a virtual `formula` field is refused, not answered with zero rows (#8296)

**BREAKING** — this is a public API contract change on the query engine, not a
plain bug fix: a `where` on a `formula` field used to succeed (with the wrong
answer) and now throws. Every call site that reaches `assertFilterIsMaterializable`
— `engine.find`, `findOne`, `count`, `aggregate`, `update`, `delete` — can newly
raise `400 INVALID_FIELD` for input it previously accepted with a `200`. Graded
`minor`, not `major`: every publishable package sits in the Changesets `fixed`
lockstep group during the launch window (`scripts/check-changeset-no-major.mjs`),
so a `major` here would promote the whole ~70-package stack for one engine seam.
See "What to change if this refuses one of your queries" below for the fix.

`formula` is the one field type no driver materialises a column for. Three query
axes can name a field; until now only two of them said so.

Expand DownExpand Up@@ -81,3 +91,5 @@ filtering a formula answering 0 rows with no error. It now asserts the
formula still cannot be filtered. The first sweep read app source only, which is
the wrong half: current behaviour is pinned in tests, so a behaviour change lands
there first.

<!-- adr-0087: not-required (no-migration-prescription) this is a runtime query-validation behavior change, not a spec/metadata key rename or removal -- no field, key or stored value moves, so there is nothing for the migration ledger or `objectstack migrate meta` to register. The guidance above (denormalise onto a stored field and filter that) is behavioral advice for API consumers, not a mechanical rewrite of stored metadata. -->
Loading