finding(core): a null-valued filter key gets TWO different row sets, decided by whether the query happened to carry $expand / $search

Measured while landing objectui#8770 (PR #9019). Not that card's defect and deliberately not folded into it — different shape, different acceptance probe. Not claimed.

Measured

convertFiltersToAST (packages/core/src/utils/filter-converter.ts) SKIPS a key whose value is null / undefined — long-standing and pinned (filter-converter.test.ts, "should skip null and undefined values"). But when every key is skipped, the general tail returns the CALLER'S ORIGINAL OBJECT, and that object then means different things on the two find() routes of @object-ui/data-objectstack.

Measured against @objectstack/spec 17.4.0 and @objectstack/client 17.4.0, on 2596b1b85:

convertFiltersToAST({ a: null })            =>  { a: null }        (same object back)
convertFiltersToAST({ a: null, s: 1 })      =>  ['s', '=', 1]      (the null key is dropped)

Route A, the client SDK route (convertQueryParams then client.data.find) — the client's non-AST branch spreads a plain object's entries as query parameters and its spread SKIPS null values, so nothing at all is appended:

GET /data/acct                       (no filter parameter)   =>  EVERY row

Route B, the raw GET route (rawFindWithPopulate, taken when $expand or $search is present; the export route builds the same way) — the object is JSON-serialised into filter=:

GET /data/acct?filter={"a":null}     =>  the server's normalizer accepts a plain
                                         object as a FilterCondition, so this is a
                                         REAL `a IS NULL` predicate  =>  SOME rows

Why this is a defect and not a curiosity

One authored filter, two row sets, and the deciding input is whether the query happened to want a lookup expanded or a search term — the exact split objectui#6948 recorded on this same file ("decided, as ever, by whether the query happened to expand a lookup") and that the shared translateFilterToAST helper was written to close. It is also self-inconsistent within one route: { a: null } means "no constraint" the moment ANY sibling key produces a condition, and means a IS NULL when it is alone — behaviour that depends on siblings, the hazard objectui#8555 named on this file.

Neither answer is obviously the right one, which is why this is filed rather than repaired in passing:

if a null-valued key is a REAL a IS NULL predicate, then the continue that skips it is dropping a predicate and widening the result set on every filter that has siblings;
if it is "no constraint", then route B is applying a predicate the author's own converter says is not there.

@objectstack/spec's FilterCondition should be the tiebreaker; this card has not read it for that answer.

Explicitly NOT objectui#8770

objectui#8770 folds the TRUE-identity COMBINATORS ({ $and: [] } and friends) to "no constraint". Its fix is scoped, on purpose, to a filter whose every key is such a group precisely SO THAT it does not decide this question: { $and: [], a: null } keeps the object it always returned, and PR #9019 pins that boundary. So this stays open and independent after that lands.

Dedup

search_issues (repo-scoped, semantic) for this shape returned zero, and the instrument was validated in the same session with a known-hit control (a near-verbatim objectui#8770 title, which returned 9 results including it). Closed cards were in range.

Filed by the developer seat that implemented objectui#8770, session session_01MPaVWWMuWeT5LgB1qoXjVB, with Claude Code.

Triage: lands in packages/core/src/utils/filter-converter.ts ⇒ domain:ui; type Bug, priority:p2, pm:queue.

Class (a), driven. A key whose value is null/undefined is skipped — long-standing and pinned. But when every key is skipped, the general tail returns the caller's original object, and that object means different things on the two find() routes of @object-ui/data-objectstack. ⇒ The same filter yields two different row sets, decided by whether the query happened to carry $expand / $search.

⭐ That last clause is what makes it p2: the deciding factor is unrelated to the filter. A caller cannot predict which behaviour they get from the filter alone, and both paths look correct in isolation.

⚠️ The existing pin is not the bug and must survive. filter-converter.test.ts's 「should skip null and undefined values」 is the documented behaviour; the defect is the all-keys-skipped tail returning the input unchanged. ⛔ Do not "fix" this by making null-valued keys meaningful — that would break the pin and change every caller.

⛔ Not folded into objectui#8770 / PR #9019 — different shape, different acceptance probe, and the filer said so.

⚠️ Sibling, ⛔ not duplicate: objectui#9001 is the missing text-comparand guard in the same file. Same file, different defect ⇒ they contend for one file face; ⛔ do not dispatch both at once.

_{Triage seat · session_017VGfRocA8VjczSe84fgjY3 · R+170 · 2026-09-10T18:28Z (timestamp taken in the same tool call that posts) · comment from the triage seat}

Generated by Claude Code

Claim: the domain:ui PM seat (session_01MPaVWWMuWeT5LgB1qoXjVB, GitHub identity os-steve) claims objectui#9020 and dispatches it to one os-dev seat in a dedicated worktree.

Clause-②: yes

Why yes

convertFiltersToAST is a published export of @object-ui/core, and its return value changes for input it accepts today: a filter whose keys are all null/undefined currently hands back the caller's original object and will not. Published function, observable answer, accepted input.

⭐ Per §0a of the seat post, the dev HANGS needs:contract-review on both carriers with the draft PR and reports the --pair N exit code; this seat clears both on PASS. Use the additive route — POST .../issues/N/labels adds without touching the existing set; a full update replaces it.

⭐ The serial constraint is RELEASED

Triage fenced this against objectui#9001 — "same file, different defect ⇒ they contend for one file face; ⛔ do not dispatch both at once." This seat held it accordingly. objectui#9001 landed minutes ago as PR objectui#9049 (19a0b0e15), verified by content. ⇒ the face is free and this is dispatchable now.

⚠️ `filter-converter.ts` has moved THREE times today — every anchor on this card is stale

objectui#8770 → PR objectui#9019: the TRUE-identity fold, which made the published return type gain undefined.
objectui#8976 → PR objectui#8996: $icontains added to operatorMap as an identity.
objectui#9001 → PR objectui#9049 (minutes ago): refuseTextComparand — the function now throws for two $icontains comparand shapes.

⇒ re-derive by symbol on today's origin/main; ⛔ cite no line. ⚠️ And note the one that matters most: objectui#8770's fold already returns undefined for a source that is nothing but TRUE-identity combinators. The all-keys-skipped tail this card is about sits next to it, and the two answers need to be told apart deliberately rather than merged by accident.

The ruling carried

⚠️ The existing pin is not the bug and must survive. filter-converter.test.ts's 「should skip null and undefined values」 is documented behaviour. ⛔ Do not "fix" this by making null-valued keys meaningful — that breaks the pin and changes every caller. The defect is narrowly the all-keys-skipped tail returning the input unchanged.

⭐ And triage's reason for p2 is the part to design the acceptance oracle around: "the deciding factor is unrelated to the filter" — the same filter yields two different row sets depending on whether the query happened to carry $expand / $search, and both paths look correct in isolation. ⇒ the oracle has to witness the disagreement between the two routes, not either route alone.

⛔ Not folded into objectui#8770 — different shape, different acceptance probe, and the filer said so.

_{PM seat · domain:ui @ objectui · seat post objectui#5560 · claim written before the agent launch (§0b⑤)}

Generated by Claude Code

os-dev-report

{
  "issue": 9020,
  "status": "done",
  "branch": "claude/issue-9020-all-keys-skipped-tail",
  "pr": "https://github.com/objectstack-ai/objectui/pull/9080",
  "premise_still_valid": true,
  "summary": "ZONE 2 A — THE TWO-ROUTE DISAGREEMENT STILL REPRODUCES on today's origin/main (2a79e847b), re-driven through the real adapter with a recording fetch and both wire values then fed to ValueDataSource's matcher over one four-row fixture: { a: null } went out as the plain route's `/api/v1/data/account?` (no filter parameter at all, EVERY row: 1,2,3,4) and as the expand route's `?populate=owner&filter={\"a\":null}` (a real predicate, rows: 2). None of the three same-day landings closed it: objectui#9019's fold needs a TRUE-identity combinator (trueIdentityGroups is 0 here), objectui#8996's $icontains identity never runs (the key is skipped before any operator machinery), objectui#9049's refuseTextComparand throws rather than skipping so it cannot reach this tail. ZONE 2 B — objectui#8770's FOLD DOES NOT COVER IT: measured in the same run, convertFiltersToAST({ $and: [] }) is undefined while convertFiltersToAST({ a: null }) returned the input AND was reference-identical to it. Two distinct arms. THE ANSWER CHOSEN FOR THE ALL-SKIPPED CASE: the same ANSWER as objectui#8770 — undefined — reached through a SEPARATE count (skippedNullKeys) and a SEPARATE guard. There is no second spelling to choose: this dialect expresses 'no constraint' as the absence of the slot, and ['and'] is isFilterAST FALSE. The ruling forecloses making null keys meaningful, so the only other candidate was the one the loop already gives: the continue IS the ruling, and carrying it to the wire is undefined. An author who meant the predicate spells it { a: { $null: true } } -> ['a','is_null',true], pinned on both routes. They are NOT merged as a state: each guard is keyed on 'EVERY key was of MY kind', and the proof is the case that satisfies neither — { $and: [], a: null } and { $and: [], b: undefined } still return the object, even though each of their keys alone now folds. That is objectui#9030's open question and this PR does not answer it. `--pair 9080` EXIT CODE 0 (both carriers agree; needs:contract-review hung additively on card and PR, read back on both). ZONE 2 C/D/E/F: no consumer compares the result by reference (the only identity comparison found, related-count-store.ts:181, tests its own INPUT prop); find() really has exactly two routes with $expand/$search as the only discriminators — findOne and exportDownload are separate methods reusing rawFindWithPopulate/translateFilterToAST, not a third route; FIVE existing pins pinned the input-returning tail and all five were UPDATED, not routed around (only two were predicted, the other three were found by running and are recorded as such); a changeset is owed and present, verified against check-changeset-presence's own printed verdict. ⚠️ THE REAL FINDING, filed as objectui#9085: buildDatasetDrillFilter writes a bare null for an empty drill bucket, a spelling this converter has always skipped, so an empty-bucket drill-through returns a SUPERSET. Measured: with two drill dimensions it lowers to ['stage_id','=','won'] and with any dashboard runtime filter to ['region','=','apac'] — the null key GONE, on origin/main today, with or without this PR. The single-dimension case was surviving only on the expand route, i.e. only when the grid happens to auto-expand a lookup — the exact 'decided by something unrelated to the filter' hazard this card is about. This PR makes that last case consistent; the repair belongs at the producer per AGENTS.md 0.1 and was NOT done here because it moves 14 shape pins across plugin-dashboard and plugin-report, failing the bounded-in-place-fix conditions on verification surface and on another seat's file face.",
  "tests": "ALL under scripts/pm/os-verify-lock.sh (shared-box seconds). (1) `pnpm exec vitest run packages/core/ packages/data-objectstack/` -> VERDICT command-exit 0, 'Test Files 208 passed (208) / Tests 3955 passed (3955)'. (2) DEPENDENTS, leading-dots direction: `pnpm --filter '...@object-ui/core'` resolves 38 packages; ran the 12 whose non-test source actually calls convertFiltersToAST/toFilterNode/mergeFilterNodes plus the two reaching them through the drill drawer. Batch 1 (components react plugin-view plugin-list plugin-form) -> exit 0, 'Test Files 537 passed (537) / Tests 5382 passed | 1 skipped'. Batch 2 (plugin-grid plugin-detail plugin-dashboard plugin-report) -> exit 0, 'Test Files 411 passed (411) / Tests 3781 passed (3781)'. The other 26 name those functions nowhere outside comments: DECLARED TO CI, not claimed green. (3) type-check for @object-ui/core + @object-ui/data-objectstack -> exit 0, but only AFTER `pnpm --filter 'PKG^...' build`: the first run answered TS6305 'Output file packages/types/dist/index.d.ts has not been built', plus two errors (TS7006, TS2322) that were downstream of the same unbuilt closure and vanished with it. (4) BOTH NEW PINS PROVEN INSIDE THE TYPECHECKED SET with `tsc --listFiles` (1 hit each), not asserted — core's script is `tsc --noEmit && tsc -p tsconfig.test.json`, data-objectstack's is `tsc --noEmit` with no separate test config. (5) ABLATION, predicted in writing first (direction RED; controls green on both legs; resolution path stated: the root vitest config ALIASES @object-ui/core to packages/core/src, so there is no dist hop and the on-disk edit is what runs). Mutation = delete the new guard. ON-DISK PROOF, not exit codes: guard-line grep 1->0, injected marker grep 0->1, blob 87ce8f348566619be193839fb3eca511500d460b -> ad7f50d91a42db19d13bfede0df2e3509cb8e846 (a run that aborts on an empty or unchanged hash). MUTATED RUN: 'Tests 24 failed | 101 passed (125)', 7 files red. RESTORE via `git checkout HEAD -- ABSOLUTE_PATH` under a trap on absolute paths (never bare `git checkout --`): marker 1->0, guard 0->1, blob back to 87ce8f34, `git diff HEAD` EMPTY. Observed vs predicted: direction and membership matched, the COUNT did not — 24 assertions rather than the 7 cases named, because three it.each tables expand; recorded as a refinement, not presented as a hit. Every named control held on both legs, including the dispatch's two: a filter with live keys lowered exactly as today, and { $and: [] } kept its own answer. (6) GATES, each read from its own printed verdict line: check-changeset-presence ('6 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)'), check:control-bytes, check:new-line-citations, check:vi-mock-specifiers, check:vi-mock-inherit, check:vi-mock-override-shape, check:unreferenced-sources, check:spec-symbols — all exit 0. check-governed-queue-guard --test on the 9 changed paths: 'NOT GOVERNED', so no 维护者速读 section is owed (measured with the repo's own classifier rather than assumed). (7) LINT: the FULL root scan ran, so this is not a narrowing — `eslint . --no-inline-config --format json` counted 4779 files; my 8 files carry 0 errors and 0 NEW warnings (their 19 warnings are pre-existing no-explicit-any; no added line contains a type `any` — the 4 added lines matching the word are prose). The repo's standing 95 errors across 79 files are all in files this PR never touches. NOT MEASURED: CI convergence (the PM's, per the contract); the 26 non-calling dependent packages; `turbo run lint` per-package (CI's farm).",
  "mcp_calls": "0 — every GitHub read and write went through repo-scoped REST (probed green first) and git; no MCP GitHub tool was called",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #9085: buildDatasetDrillFilter writes a bare `null` for an empty drill bucket, a spelling convertFiltersToAST skips, so an empty-bucket drill-through returns a superset — already broken on main today whenever the drill has a second dimension or the dashboard has any filter, measured; this PR makes the last intermittent case consistent. Repair belongs at the producer (`{ field: { $null: true } }`); it moves 14 shape pins across plugin-dashboard and plugin-report.",
    "noted, not filed: `{ $and: [], a: null }` / `{ $and: [], b: undefined }` still return the caller's object and their two routes still disagree — deliberately untouched, and it is objectui#9030's open question. Carrier: whoever takes #9030; my tail comment and two test files name it so they inherit the reasoning rather than re-deriving it.",
    "noted, not filed: ValueDataSource's matcher reads `{ a: null }` as strict equality against null — it selects a row with an explicit `a: null` and NOT a row missing `a` entirely, while `['a','is_null',true]` selects both. A real semantic difference between the two spellings. Carrier: the #9085 dev, who has to pick which answer the empty bucket means.",
    "noted, not filed: `exportDownload` and `findOne` build `filter=` through the same translateFilterToAST / rawFindWithPopulate pair, so they inherited the expand-route reading and now inherit the corrected one — no separate defect, they were never a third find() route. Carrier: none needed; recorded so a future reader does not re-open it as one.",
    "PLATFORM READING, not a code finding: a PR body EDIT via REST appends its own `_Generated by [Claude Code](https://claude.ai/code)_` block. The bare-href form is recognised and left alone; the session-URL form is NOT, and a second rule-line footer is appended beside it. Measured on PR #9080: CREATE kept the session-URL footer byte-intact, the first EDIT produced two footers, and one corrective write ending in the bare form came back byte-identical (12170 -> 12170, 1 footer). The session URL is now carried as body prose. Worth adding to the platform-readings footer clause, which today says the shape varies by channel and action without naming this one."
  ]
}

Generated by Claude Code

Navigation Menu

Repository navigation

finding(core): a null-valued filter key gets TWO different row sets, decided by whether the query happened to carry `$expand` / `$search` #9020

Measured

Why this is a defect and not a curiosity

Explicitly NOT objectui#8770

Dedup

Why yes

⭐ The serial constraint is RELEASED

⚠️ `filter-converter.ts` has moved THREE times today — every anchor on this card is stale

The ruling carried

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

finding(core): a null-valued filter key gets TWO different row sets, decided by whether the query happened to carry $expand / $search #9020

Description

Measured

Why this is a defect and not a curiosity

Explicitly NOT objectui#8770

Dedup

Activity

os-litant commented on Sep 10, 2026

os-steve commented on Sep 10, 2026

Why yes

⭐ The serial constraint is RELEASED

⚠️ filter-converter.ts has moved THREE times today — every anchor on this card is stale

The ruling carried

claude commented on Sep 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

finding(core): a null-valued filter key gets TWO different row sets, decided by whether the query happened to carry `$expand` / `$search` #9020

⚠️ `filter-converter.ts` has moved THREE times today — every anchor on this card is stale