Four live `adapter.find` calls pass an unprefixed query option — and `no-query-params-under-options` gates only the sibling half of the class

[os-zhuang]

Moved from objectstack-ai/objectstack#10470 by the triage seat (file-at-destination rule: every named site and the rule that should gate them live in this repo). Original filed 2026-08-21 by os-zhuang from the objectstack-ai/objectstack#10288 dev seat. Body reproduced verbatim below with bare issue refs qualified.

---

Census taken at objectui c40f3b8ca21ddc19e05682f1719fcf16d4ce7fba (objectstack pins 9a3daf8d37ad973a621e5edd276fe32467f90684; re-confirm at the pin before acting).

The class

QueryParams (packages/types/src/data.ts) declares only $-prefixed keys, and ObjectStackAdapter.convertQueryParams (packages/data-objectstack/src/index.ts) builds its outgoing options by copying exactly those. Any other key reaches no branch and is dropped — no throw, no warning. QueryParams also carries an index signature, so the type system accepts both spellings equally.

The consequence is an unbounded read, not a truncated one: the platform's GET list route has no default page size (objectstack packages/client/src/index.ts, pinned in its client.test.ts), so an absent top returns the entire match set. A dropped cap is therefore invisible until the object is large.

The four live sites

file	call	dropped key
apps/console/src/sdui-workbench-preview.tsx:65	find(objectName, { top: 200 })	top
packages/app-shell/src/views/ObjectView.tsx:1561	find(…, { limit: 0 })	limit
packages/app-shell/src/views/metadata-admin/AssignedUsersSection.tsx:109	find('sys_permission_set', { $filter: {…}, limit: 1 })	limit
content/docs/guide/react-pages.md:129	find(…, { filters: [['status','=','open']] })	filters

ObjectView.tsx:1561's limit: 0 is worth reading twice: $top: 0 is honoured end to end as "no records" (objectstack-ai/objectstack#6485 pinned it), so if that call means what it says, dropping the key inverts it from no rows to every row.

AssignedUsersSection.tsx:109 is a one-line-away neighbour of three correct calls ($top: 500, $top: 200, $top: 1000 on L124/131/136) — the shape a reviewer's eye slides over.

sdui-workbench-preview.tsx:66 also reads all.records off the result, with no .data arm. find() resolves to a QueryResult (data, never records), so that preview lists nothing regardless of the cap. skills/objectui/guides/data-integration.md:268 publishes the same return result.records; to skill consumers.

Why a rule, and which one

eslint-rules/no-query-params-under-options.js already gates the sibling shape — find(obj, { options: { $top: 100 } }) — and its own header makes the argument for mechanising this family: the mistake type-checks, it publishes, the symptom looks like a data problem rather than a code problem, "so a review catches it once and then misses the next one." It cites two live instances by two authors (object-timeline, objectui#4009 / objectstack-ai/objectstack#7137; object-kanban, objectui#4025).

The rule bans a $-prefixed key under options. It does not look at a bare key at the top level, which is the other half of the same class — and the half with four live sites. Extending it (or adding a sibling rule) is the cheap move: the AST walk already lands on the params object literal of a find/findOne call, the fix is a second predicate, and the contract lives in the same repo as the rule.

Suggested shape, narrow on purpose: flag a static key that is a known query-option name without its $ (top, skip, filter, filters, select, orderby, sort, expand, search, count, limit, offset) in the second argument of an adapter.find / dataSource.find / …findOne call. Not "any unprefixed key" — adapters legitimately take adapter-specific params, which is why the index signature exists.

An objectstack-side gate was considered for objectstack-ai/objectstack#10288 and rejected: QueryParams is objectui's contract, so a checker there would have to hard-code another repo's key list and become a second source of truth for it. The rule belongs next to the type it enforces.

Related

• examples: the showcase renewals react page passes top: 500 to adapter.find, which is not a query option — the rollup silently reads only the first page objectstack#10288 — the same two defects in examples/app-showcase, fixed there.
• docs(ui): the react-pages live-data sample reads result.records, which is always undefined — and its Callout misstates what a dropped option does objectstack#10469 — the same .records misread in objectstack's own react-pages guide (queued there, devx lane).
• objectui#4734 / object-kanban 的行上限写在 options: { $top: 100 } 里 —— 这个键不属于 QueryParams,没有任何 adapter 读它,窗口从未上线 objectstack#7147 — the options: { $top } half, already gated.

[os-warren]

Claim: PM loop round 3
Session: session_01PQ3NihCHE9LUtHoGxo6A9f
Branch: claude/issue-5458-unprefixed-query-options
Worktree: objectui-issue-5458
Domain: domain:devx (@ objectui, seat #5748)
File surface: eslint-rules/no-query-params-under-options.js + its test; apps/console/src/sdui-workbench-preview.tsx; packages/app-shell/src/views/ObjectView.tsx; packages/app-shell/src/views/metadata-admin/AssignedUsersSection.tsx. (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus — the rule's scope is a judgement call. ⚠️ Tier is this seat's explicit decision; scripts/pm/dispatch-gates.mjs does not exist in objectui.
Clause-②: no — and the boundary is load-bearing here, so read the constraint below. A lint rule that refuses more shapes tightens; it does not widen an acceptance set. What would be Clause-② is changing convertQueryParams to start honouring unprefixed keys, and that is forbidden below.
Serial constraints cleared: PR #5925 is open against packages/app-shell/ — src/preview/DraftChangesPanel.tsx, comment-only, disjoint from the two src/views/** files here; read but ⛔ do not touch. Other open PRs by head: #5922 (layout docs), #5843 (governed docs/adr), #5774 (.github/workflows/ + ci-cd-pipeline.md), #5400 (release), #4958 (dependabot) — none intersect. Concurrent in this batch: #3840, which touches apps/console/src/__tests__/public-block-binding-reach.test.tsx only — disjoint from your apps/console file, but ⛔ do not edit that probe.

⚠️ The census has changed since the card was written — 3 live sites, not 4

Re-measured on origin/main @ 2074a59. The card's census was taken at c40f3b8ca, and the fourth site is already fixed. Use this table, ⛔ not the card's:

site	card said	measured now
apps/console/src/sdui-workbench-preview.tsx	:65, find(…, { top: 200 })	live, moved to :86
packages/app-shell/src/views/ObjectView.tsx	:1561, find(…, { limit: 0 })	live, moved to :1687
.../metadata-admin/AssignedUsersSection.tsx	:109, find(…, { …, limit: 1 })	live, still :109
content/docs/guide/react-pages.md	:129, find(…, { filters: [[…]] })	ALREADY FIXED — :231 now reads $filter: ['status', '=', 'open'], and :243 documents the rule in prose

That doc page is now an ally, not a target: it already tells readers "An unprefixed filters: or top: is not a query option". ⛔ Do not re-fix it, and do not count it in your before/after. Every line number above is a lead — re-derive from the tree, ⛔ do not trust mine either.

Why this matters more than a lint nit

The failure is an unbounded read, not a truncated one. The platform's GET list route has no default page size, so a dropped cap returns the entire match set — invisible until the object is large. And ObjectView.tsx's limit: 0 inverts: $top: 0 is honoured end-to-end as no records, so dropping the key turns "no rows" into "every row". Establish what that call is actually meant to do before you rewrite it — ⛔ a mechanical limit → $top there could be the wrong fix if the intent was never "no rows".

AssignedUsersSection.tsx:109 sits one line from three correct calls ($top: 500 / 200 / 1000) — the shape a reviewer's eye slides over, which is the argument for the rule.

⛔ Hard constraint — fix the call sites, not the adapter

QueryParams declares only $-prefixed keys and convertQueryParams copies exactly those; the index signature is deliberate, because adapters legitimately take adapter-specific params. ⛔ Do not make the adapter start accepting unprefixed keys — that widens the acceptance set, which is Clause-② work and a maintainer-floor decision, not this card's. If you conclude the adapter is the right place, stop and report rather than doing it.

The rule — narrow on purpose

Extend no-query-params-under-options (or add a sibling; justify whichever you pick). The AST walk already lands on the params object of a find/findOne call, so this is a second predicate: flag a static key that is a known query-option name missing its $ — top, skip, filter, filters, select, orderby, sort, expand, search, count, limit, offset — in the second argument. ⛔ Not "any unprefixed key" — that would flag the legitimate adapter-specific params the index signature exists for, and a rule that cries wolf gets disabled.

Requirements on the rule:

1. It must fail on all three live sites before your fix and pass after. Show both runs. A rule that only passes after the call sites are already fixed proves nothing about the rule.
2. It must not flag the correct neighbours ($top: 500 / 200 / 1000 in the same file) — assert that explicitly, it is the false-positive control.
3. The existing sibling half ({ options: { $top: 100 } }) must keep failing. ⛔ No regression in what is already gated.
4. The rule must be wired into the lint config that CI actually runs. An unregistered rule file is a no-op that looks like a fix — verify by making it fire, not by reading config.

One more thing the card noticed, and it is a real second defect

sdui-workbench-preview.tsx reads all.records off the result, but find() resolves to a QueryResult (data, never records) — so that preview lists nothing regardless of the cap. Fix it while you are in the file. ⚠️ skills/objectui/guides/data-integration.md:268 publishes the same return result.records; to skill consumers — that is a published skills surface. ⛔ Do not edit skills/** on this card; if it is still wrong on today's tree, report it and I will file it, since published skill packages are evaluated whole-package and carry their own line budget.

Premise-first

The body is a lead, not a specification. If a site is already fixed — one of four already was — report the measurement instead of manufacturing a diff. Read the card on GitHub yourself and check the body for sanitizer truncation; note it was moved verbatim from objectstack#10470, so bare refs there were rewritten.

---

Generated by Claude Code