[kriszyp]

⊙ Problem

Search and filtered REST reads with select(...) (GET /Article/?id=a1&select(id,meta{summary})) run nested JSON through the outer table's resolvers. A nested key named like an outer @computed, @relationship or $id returns that resolver's output instead: another table's record, a promise, or an error row. Selecting toString errors the row.

🤔 Is search/single-record parity the right contract?

Yes, as specified: both read the same stored data, and single-record reads already return it.

💡 Solution

• Search rows equal the single-record projection: nested JSON returns stored values; only real relationships resolve.
• computedMeta{publicSummary} returns only publicSummary.
• Fixes Nested Resource projection fails to settle asynchronous arrays and forceNulls.
• Sub-select rules from Fix REST and operations API select projection defects (sort, offset, limit, {name} and * as identity) now apply to plain JSON without the outer resolvers.

🤔 Narrowed @computed results are client-visible

A client that relied on getting the full object back from computed{field} now gets only field. That is the documented meaning of a sub-select and matches single-record reads.

🤔 A nested {name} with no list now returns the value, not a 400

This PR first made that shape a 400. #3221, now on main, made it an identity transform, which children[sort(-id)] needs. This PR keeps main's contract on both paths and tests it for parity.

⚖️ Alternatives

Two rejected approaches, and why the null-prototype resolver map breaks no index

• Object.hasOwn at the one search lookup — leaves the other propertyResolvers[x] readers (index maintenance, search, derived indexes) exposed; the null prototype fixes them all at construction.
• Route all search projection through Resource.transformForSelect — loses entry-level work it does not do (lazy loads, source revalidation, row filters, per-table read transactions).

Does the null-prototype resolver map change existing indexes?
No: on main an indexed field named hasOwnProperty, valueOf or __proto__ made every write throw, and toString indexed every row as "[object Undefined]". No correct index exists to break. The plan review's other point, a selector-keyed cache instead of a name-keyed one, is adopted.

Framing-Verdict: better-alternative-exists (5a39ffcdb4ea)

🔧 Changes

• resources/Table.ts
  • Plain JSON values go through the resolver-free projectPlainValue, both stored sub-objects and directReturn (@computed) results. Look hardest here: this is the boundary that keeps outer resolvers off nested data.
  • One per-query Map keyed by selector also caches relationship transforms.
  • Resolved-value projections return their pending promise, so the row waits for nested async work.
  • propertyResolvers gets a null prototype.
  • Positional [*] keeps its shape, and the * copy skips functions and keeps __proto__ as data.
  • Cut per-row work on RocksDB indexed range queries, especially with a select #3605's plain-column select fast path now treats a function value as absent and leaves a __proto__ select to the general path, so both paths project alike.
  • Relationships carrying Honor nested relationship filters and pagination #3279's nested conditions/sort/offset/limit still dispatch to _prepareRelationshipSelection first in both projectors; cancellation walks the Map cache's values so cached child transforms still stop.
  • A non-list select on a caching table fails with a 400.
• resources/Resource.ts
  • __proto__ is read only as an own property.
  • Pending changes are matched by own key.
  • * alone passes the value through. With names, it copies data keys: from toJSON() for a tracked instance, none from a Buffer, Blob or Date.
  • Async values settle in positional rows, arrays and custom Resource array results, and in search. forceNulls applies after settlement.
  • One nestedSelectTransform builds every { name, select?, sort?, offset?, limit? } transform for both projectors; plain JSON gets no target table, so no resolvers.
  • Nested transforms are cached by selector.
  • A non-list object select is a 400 ClientError.
• resources/DESIGN.md — the projection boundary and its invariants.

✅ Verification

• New searchSelectProjection.test.js, 38 cases. Cases assert explicit expected values; most also assert that the search row equals the single-record projection. 16 of the first 19 cases fail on main. Passes on RocksDB and LMDB.
• relationship-and-status-contract.test.ts adds a filtered-collection REST case over JSON, CBOR and MessagePack. It fails on main and passes on both engines. The stored-__proto__ expectation now gets no data instead of {}.
• On this head (rebased onto Read related records in the background when a query selects, filters, joins or sorts on a relationship #3615): 54 select/relationship/computed unit files, 1688 passing; the one failure is a full-text upgrade test missing a local package, unrelated. relationship-and-status-contract 24/24, nested-relationship-docs 14/14.
• PR QA: passed @ d43f4ac, before the Honor nested relationship filters and pagination #3279 rebase. At d8b3842: 320/320 projection responses on RocksDB and LMDB; the merge base fails 120/160 per engine.

Earlier runs

• Before the rebase onto Fix REST and operations API select projection defects #3221: test:unit:resources 4597 passing, test:unit:main 7485 passing, test:integration:all 2590 passing / 0 failing.
• bench-run A/B: the new __proto__ and pending checks cost ≤2% on 1M projections.

Follow-ups filed from review

• Resource select projection: inherited names shadow stored data on a changed instance; iterable results not settled — item 1 is fixed here; the rest is pre-existing.
• Tracked toJSON drops a typed-struct record's stored fields once an instance has changes

Fixes #3168

_{🤖 Generated by Claude Opus 5.5 via Claude Code (dev-agent); posted via @kriszyp.}

Release target: v5.3 — fixes code from #3171, a backport to v5.3
Related PRs: #3221 overlaps (merged; reconciled in nestedSelectTransform), #3605 overlaps (merged; fast path matches selectAttribute), #3279 overlaps (merged; its constrained-relationship dispatch runs first), #3316 overlaps (its JSON authorization walk assumes nested JSON resolves outer relationships), #3615 overlaps (merged; its try/catch wraps this PR's projection body), #3430 overlaps (resources/DESIGN.md Conventions text), #3651 overlaps (selector reuse; prepared relationship selections stay name-keyed), #3619 overlaps (target-table read transaction in the relationship branch), 12 others independent
Complexity: complicated

Deferred findings

• 93da77d0a041f5d1 minor correctness — resources/tracked.ts — tracked toJSON spreads a lazy typed-struct record, dropping stored fields from * and from the unprojected response once the instance has cha — filed Tracked toJSON drops a typed-struct record's stored fields once an instance has changes #3455
• 86e58afed4fe8f06 minor correctness — resources/Table.ts — prepared relationship selections keyed by name; repeated relationship with nested options shares one projection — NOT FILED
• e59c89793ef3bdd6 minor correctness — resources/Resource.ts — lone ['*'] on resource-backed get copies via for-in while search returns record unchanged — NOT FILED
• 85b4936e675f4c82 nit correctness — resources/Resource.ts — non-Array results with .map are not settled by settleAll in static get/search — filed Resource select projection: inherited names shadow stored data on a changed instance; iterable results not settled #3454
• 63a46ea003a80572 nit correctness — resources/Resource.ts — getRecord without toJSON falls back to getRecord() only, omitting changes and own fields from * — filed Tracked toJSON drops a typed-struct record's stored fields once an instance has changes #3455
• 69cad8b03477444c nit correctness — resources/Resource.ts — *-only pass-through returns an array of pending promises unsettled — NOT FILED
• e2c2ba2c8fa72c59 nit reliability — resources/Table.ts — child transform created after return() in async resolver continuation is never stopped — NOT FILED
• dd77c6298b704852 nit maintainability — resources/Table.ts — truthy loadingFromSource?.then check inconsistent with typeof-function guards — NOT FILED

Origin — the dispatch brief this PR was written from

Fix collection/search select(...) projection in Table.transformEntryForSelect (resources/Table.ts ~6644-6890 on main). (1) The plain-JSON sub-select branch (~6833-6851) builds the nested projector from the same table class, so nested keys that share a name with an outer @computed/@relationship/$id/$score/$updatedtime resolver are resolved against the nested object (a nested plain value can be replaced by a related-table record). Project plain JSON sub-objects with the resolver-free transformForSelect (already imported), as the single-record Resource path does. (2) propertyResolvers?.[attribute_name] (~6749) has no own-property guard and propertyResolvers is a plain object literal (~8218), so selecting hasOwnProperty/valueOf/toString/constructor/proto calls an Object.prototype member and turns the row into an inline error. Build propertyResolvers with a null prototype (this also hardens the other propertyResolvers lookups). (3) For an object-returning @computed with directReturn, the sub-select is not applied, so unselected sub-fields leak; apply the sub-select before returning. Update the resources/DESIGN.md sentence that says transformEntryForSelect projects undeclared JSON sub-objects through the same form.

Acceptance

Tests on RocksDB and LMDB: nested keys named like an outer @computed (sync and async), @relationship(from/to), $id, $score, $updatedtime project the stored nested value; selectors hasOwnProperty/valueOf/toString/constructor/proto on a filtered query return the stored value or undefined, never an error row; an object-returning @computed with a sub-select omits unselected fields; parity: Table.get(id) with select equals the matching Table.search row for every case. Shown failing on origin/main.

_{Dispatch: task harper-select-projection-nested-resolvers · queued by finding-triage/wave-38 · ran by claude/opus/high · worker kzyp-xps-1}

Late Grok findings

7 surviving (highest minor) — Grok reviewed e1d3f33

• minor — resources/Table.ts:7638 — if one relationship is selected twice and either selector carries conditions, sort, offset or limit, both slots get one projection, because prepared selections are keyed by name here and at resources/Resource.ts:1242
• minor — resources/Resource.ts:1233 — a lone ['*'] select on a resource-backed get copies the record with for-in at resources/Resource.ts:1304 and drops surfaced @computed fields; search returns the record unchanged at resources/Table.ts:7717, so the two return different fields
• nit — resources/Resource.ts:1281 — a nested plain object whose then is a function is treated as a promise (also at resources/Resource.ts:1252, :1262 and :1329), so its sub-select is skipped, or the row hangs if then never calls back; only trusted @computed or caching-source code can build such an object
• nit — resources/Resource.ts:1236 — a *-only select passes an array of pending promises through unsettled (same at resources/Resource.ts:1366-1368), while children{name} settles them
• nit — resources/Table.ts:7824 — a child transform created in an async resolver continuation after transform.return() never gets its own return() call, so it reads related records after the query was cancelled; bounded to rows already in flight
• nit — resources/Table.ts:7706 — loadingFromSource?.then is a truthiness check, unlike the surrounding typeof … === 'function' guards; no normal producer of the failing shape (then set to a non-function) exists
• nit — resources/Resource.ts:1284 — added comments at resources/Resource.ts:1179 and :1284 partly restate the code

Not standing: none. Grok ran 26m (26m from launch to report); the fold adjudication (cursor-grok@e1d3f3395daa-da870c61, claude) took 1m.

_{Review-Coverage: authored=claude; ran=cursor-composer,gemini,codex,cursor-grok; late=cursor-grok:adjudicated; adjudicated=domain; declined=muse; rounds=22; full=6 @ e1d3f33}

_{Review-Attention: deep ~50m (critical: Table.ts; hot: Resource.ts; decisions: do-less-alternative, computed-results-project-plain, proto-select-json-shape, invalid-select-clienterror, null-proto-resolvers) @ e1d3f33}

[github-actions]

Release cherry-pick v5.3: conflict

Cherry-pick onto v5.3 produced conflicts on commit(s): 0ab28f8b6be13eeb817a5c4716595af2ceb17858 e1d3f3395daa60d76e9321ed0fca6265f4b33a07

The conflict markers are committed on branch cherry-pick/v5.3/pr-3456.
A pull request has been opened to land this patch: #3710

[gemini-code-assist]

Code Review

This pull request aligns search select projections with single-record projections across the Resource and Table modules. It introduces robust handling for prototype-chain properties (such as __proto__), prevents outer table resolvers from executing on nested plain JSON data, adds support for wildcard (*) selections, and ensures asynchronous array projections are properly settled. Comprehensive unit and integration tests have been added to validate these projection behaviors. There are no review comments, so I have no feedback to provide.