Data query: a dotted projection entry silently WIDENS the response — `fields:["name","account.name"]` returns every field

[huangyiirene]

Symptom

POST /api/v1/data/showcase_invoice/query with {"fields":["name","account.name"]} answers 200 returning every business field of each record, and no resolved account.name.

Expected: the projection narrows to the named columns (with the dotted path resolved), or — if a dotted path is not supported on this door — a 400 INVALID_FIELD.

Measured across three doors and two object pairs in the same run:

request	observed	expected
POST /data/showcase_invoice/query {"fields":["name","account.name"]}	200, every field, no resolved account.name	narrowed projection
GET /data/showcase_invoice?$select=name,account.name	200, every field	narrowed projection
POST /data/showcase_task/query {"fields":["title","project.name"]}	200, every field	narrowed projection
control — POST /data/showcase_task/query {"fields":["title"]}	200, correctly narrowed	—
a nonexistent dotted column	200 + every field (swallowed)	400 INVALID_FIELD
a nonexistent plain column	400 INVALID_FIELD	—

Two things are wrong at once: the request is answered with strictly more data than it asked for (a projection is how a caller keeps heavy or unwanted columns out of a response, and nothing in the body says it did not apply), and the two spellings of the same mistake — plain vs dotted unknown column — get opposite verdicts on one endpoint. The 400 INVALID_FIELD message the plain spelling produces names this exact failure mode.

Root cause

assertProjectionFieldsExist (packages/metadata-protocol/src/protocol.ts) validates only f.split('.')[0], so a dotted entry passes the ingress gate on its head segment and then defeats the projection downstream — the unknown projection name is dropped and the projection falls back to * (the engine's documented per-axis tolerance for internal callers), i.e. over-return instead of refusal.

Neighbour: #4226 (closed/completed) is the card that closed the select / sort / expand axes against silently-dropped unknown fields. Plain names behave per #4226 in this run; the dotted spelling is the leg its gate does not cover, so treat this as an uncovered leg of — or a regression against — #4226.

Reproduction

1. Boot showcase on a fresh isolated file DB (SqlDriver / better-sqlite3); authenticate as admin@objectos.ai.
2. POST /api/v1/data/showcase_invoice/query body {"fields":["name","account.name"]} → 200, every business field, no resolved account.name.
3. Same via GET /api/v1/data/showcase_invoice?$select=name,account.name.
4. Second object pair: POST /api/v1/data/showcase_task/query body {"fields":["title","project.name"]}.
5. Controls: {"fields":["title"]} narrows correctly; a nonexistent plain column answers 400 INVALID_FIELD; a nonexistent dotted column answers 200 + every field.

Source

Extracted from the QA run #7463 (framework a86db17).

[os-zhuang]

Claimed — domain:metadata seat.

• Session: session_01TXK7QuSmTF3DKWji91cmkn
• Branch: claude/issue-7532-dotted-projection-widens
• Worktree: ../objectstack-7532 (dedicated)
• File surface: packages/metadata-protocol/src/protocol.ts — assertProjectionFieldsExist, plus new pins on both doors.

PM ruling on the fork this card leaves open. The card accepts either resolving the dotted path or refusing it. The dispatch is to refuse with 400 INVALID_FIELD, and explicitly not to implement dotted-path resolution — that is a feature, whereas this card is about a door answering with strictly more data than was asked for. Refusing also makes the two spellings of one mistake agree, which is the card's second complaint. The dev is told to confirm expand is the sanctioned mechanism for related-object data and point callers at it in the PR, and to stop and report if anything in-repo indicates dotted projections are meant to be supported.

⚠️ Serialization constraint, named: #7534 is dispatched in parallel on the filter axes of this same gate family, in the same file. Neither dev may restructure the shared resolveQueryFields resolution; if either concludes it must change shape, they stop and report.

---

Generated by Claude Code

[os-zhuang]

ACCEPT — PR #7588, marked ready and armed into the merge queue. 27/27 green.

The ruling was followed on every point, including the two that were easy to skip.

• Both doors were pinned before implementing, which is what decided whether an ingress-only fix is sufficient. POST /query body fields and GET ?$select=/?select= all fold into fields via WIRE_QUERY_ALIAS_SLOTS before the gate, verified rather than assumed, with both call sites (findData, getData) traced. Had either door bypassed the gate, closing it alone would have left that door open — the answer was owed either way, and it came back measured.
• packages/driver-sql untouched, and the driver ladder filed as finding: SqlDriver's #3821 recovery ladder widens an unresolvable projection to every field #7589 carrying the measurement and a drop-in reproduction harness — unassigned, finding only, no domain:*. Evidence stayed with whoever measured it, which is the whole point of asking the dev to file it rather than filing it myself.
• resolveQueryFields unchanged, so the serialization constraint with Data query: an unknown field inside where / $filter answers 200/0 instead of 400 INVALID_FIELD — the bare-key door disagrees (#4134's uncovered sibling) #7534 held on both sides. Data query: an unknown field inside where / $filter answers 200/0 instead of 400 INVALID_FIELD — the bare-key door disagrees (#4134's uncovered sibling) #7534's diff is +150 / -0 and this one leaves the shared resolution alone; neither dev reshaped the helper while the other was in flight.

The card's attribution was corrected, and that correction is worth keeping. The card placed the widening at the ingress gate. It is one layer lower: the protocol forwards ['title','project_id.name'] to the driver verbatim, and SqlDriver's #3821 recovery ladder is what retries select('*') after sqlite answers no such column. Both halves were driven directly — protocol through a stub driver, driver through real better-sqlite3 — so the ruling's split between "what this card fixes" and "what gets its own issue" rests on measurement rather than on my say-so.

Two things I'd single out in the verification:

• An existing test that pinned the old behaviour was inverted, with the reason recorded. query-expression-conformance.test.ts asserted a dotted path "is still accepted — the head segment is validated here, the tail resolved downstream". The tail is resolved nowhere, which is exactly what the measurement shows — so that test was protecting the defect. Flipping it and writing down why is correct; quietly deleting it would not have been.
• The narrowing assertions are exact key sets, not absence checks. expect(Object.keys(record).sort()).toEqual([...]) rather than "does not contain X" — and that detail is load-bearing here, because an over-return defect passes every absence check ever written. 8 predicted reds, exactly 8 on revert, no missed predictions.

Ruling on the follow-up, recorded here as decided rather than pending: the in-repo surfaces that still prescribe a dotted fields path describe behaviour no driver implements, and are now additionally contradicted by a 400. Aligning them is a restore-invariant fix (declared = enforced), not an open product question — the direction was already settled by this card, since dotted-path resolution is a feature it explicitly did not authorise. It was correctly kept out of this PR: cross-package spec/docs surface that regenerates artifacts, with #7534 in flight in the same file family, is the collision the serialization constraint exists to prevent. Now filed as #7601, carrying the surfaces table with the normative one (packages/spec/src/data/query.zod.ts:484) called out first, the coherent split (the zod schema is a shape check and should keep parsing a dotted string; the prose and generated artifacts are the fix), and the measured expand sharp edge — the projection must retain the foreign-key column, or expansion has nothing to resolve.

Verified independently: three files, no docs/adr/**, no content/docs/releases/, changeset present, Fixes #7532 as the first line, and the gate jobs' own conclusions (ESLint success, TypeScript Type Check success) rather than the aggregate. The tsc note in the report — 63 errors, identical count at base, none in protocol.ts — matches the gate's own reading.

---

Generated by Claude Code