finding: SqlDriver's #3821 recovery ladder widens an unresolvable projection to every field

[claude]

What this is

A finding, filed as defence-in-depth rather than a live user-facing defect. Extracted while implementing #7532; the measurement is mine and is reproduced in full below.

Once #7532 lands (PR: #7588), the ingress gate refuses a dotted projection before it reaches a driver, so no request from the REST/protocol doors arrives carrying the projection that triggers this. What remains is every caller that reaches SqlDriver without passing that ingress — hooks, flows, reports, expand sub-reads, registry-less hosts — for which this behaviour is unchanged.

Observed

SqlDriver's unknown-column recovery ladder (packages/drivers/driver-sql/src/sql-driver.ts, ~L3395-3425) catches no such column and retries the query with select('*'). The result is that a projection the driver cannot apply comes back as every column, with a 200 and nothing in the response indicating the projection was dropped.

Driven against a REAL SqlDriver over better-sqlite3 (:memory:), calling driver.find directly — no engine, no protocol, so this is the driver's own behaviour and not the ingress gate's:

A  no projection (baseline)      -> [account, amount, created_at, id, name, status, updated_at]
B  fields ['name']               -> [name]                                    <- narrows correctly
C  fields ['name','account.name'] -> [account, amount, created_at, id, name, status, updated_at]
D  fields ['account.name']        -> [account, amount, created_at, id, name, status, updated_at]

Rows C and D are byte-identical to row A — to asking for no projection at all. Knex renders "account"."name" against a table that was never joined, sqlite answers no such column, and the ladder retries selecting everything.

Reproduction harness (drop into packages/drivers/driver-sql/src/):

import { describe, it, expect, beforeEach, afterEach } from 'vitest';
import { SqlDriver } from '../src/index.js';

describe('SqlDriver projection widening', () => {
  let driver: SqlDriver;
  beforeEach(async () => {
    driver = new SqlDriver({
      client: 'better-sqlite3',
      connection: { filename: ':memory:' },
      useNullAsDefault: true,
    });
    await driver.initObjects([
      { name: 'showcase_project', fields: { name: { type: 'string' } } },
      { name: 'showcase_invoice', fields: {
          name: { type: 'string' }, amount: { type: 'number' },
          status: { type: 'string' },
          account: { type: 'lookup', reference: 'showcase_project' },
      } },
    ]);
    await driver.create('showcase_project', { id: 'p1', name: 'Apollo' } as any);
    await driver.create('showcase_invoice', {
      id: 'i1', name: 'INV-1', amount: 100, status: 'open', account: 'p1',
    } as any);
  });
  afterEach(async () => { await driver.disconnect(); });

  it('widens instead of narrowing', async () => {
    const rows: any[] = await driver.find('showcase_invoice', { fields: ['name', 'account.name'] } as any);
    // Observed: every column. A projection that cannot be applied returns MORE.
    expect(Object.keys(rows[0]).sort()).toEqual(['name']);
  });
});

Why it is deliberate today, and why it is still worth a card

The ladder is documented and intentional — its own comment explains the trade: a $select naming a column the table lacks used to make the WHOLE query fail, which read to the UI as "no records exist" while rows were there. Returning the rows without the projection was judged the lesser harm, and it explicitly backstops hosts whose registry is not populated ("notably the cloud multi-tenant runtime, where the projection otherwise zeroes the list").

That reasoning is sound for the case it was written for — an unknown plain column, which is simply absent from each row. It generalises badly to a projection the driver cannot apply for a structural reason: the caller asked to narrow, and silently received everything, which points away from both FLS and data minimisation. Nothing in the response distinguishes "your projection was applied" from "your projection was discarded".

Not fixed here, deliberately

Narrowing a documented tolerance is a contract change with its own blast radius and needs its own reverse verification — it is not a rider on #7532, and #7532's ruling was explicit that the ingress gate is where that card lands. Filed unassigned and without a domain:* label so routing stays the triage seat's call.

Related: #7532 (ingress refusal), #3821 (the ladder's origin), #4226 (the projection axis' unknown-name gate).

---

Generated by Claude Code

[os-zhuang]

Findings triage (route A) — appended domain:drivers. Routing only: the finding grade is unchanged and this seat takes no ownership.

• Landing rationale: the behaviour under question is SqlDriver's own unknown-column recovery ladder — verified on origin/main @ 744b8f5 at packages/drivers/driver-sql/src/sql-driver.ts ~L3395-3425 (no such column catch, documented projection-footgun comment, retries.push(() => buildBase().select('*'))). Any narrowing of that tolerance lands in packages/drivers/driver-sql ⇒ domain:drivers per the package table. The 2026-08-05 investment freeze ([裁决] driver-memory / driver-mongodb 投入冻结 —— 维护者 2026-08-05 口径（跨单锚点） #5499) covers driver-memory / driver-mongodb only — driver-sql is unaffected.
• Grade note (unchanged): correctly filed as defence-in-depth — once Data query: a dotted projection entry silently WIDENS the response — fields:["name","account.name"] returns every field #7532 (PR fix(metadata-protocol): refuse a dotted projection instead of widening the response to every field (#7532) #7588, in flight) lands, ingress refuses the triggering projection; what remains is the non-ingress caller set. Re-grade candidate after Data query: a dotted projection entry silently WIDENS the response — fields:["name","account.name"] returns every field #7532 merges: whether the residual surface (hooks/flows/expand sub-reads/registry-less hosts) justifies promoting a contract-change card on the ladder itself.
• Dedup: Data query: a dotted projection entry silently WIDENS the response — fields:["name","account.name"] returns every field #7532 (pm:dispatched) is the ingress half and explicitly excludes this; fix(sharing): 共享规则新建页 — 自定义 widget 未国际化，且「接收方」永远无可选项 #3821/REST 列表：sort / select / expand 指向不存在的字段时被静默丢弃（filter 轴已收口，这三条轴还没有） #4226 are the ladder's history. No competing open card on the ladder's widening behaviour.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-help]

Finding transfer from #7601's dev (spec-surface seat relaying — recorded here because it sits inside this card's mechanism; no new card filed, dedup-checked):

packages/objectql/src/engine.ts:6760-6763 carries a false implementation comment and the head-only validation it explains:

// Keep relationship paths like `owner.name` — the engine will
// resolve those via populate; only validate top-level segment.
const head = f.split('.')[0];
return known.has(head);

There is no populate step in the engine (measured in #7601; content/docs/data-modeling/queries.mdx says so in as many words). This head-only check is what lets a dotted entry survive into the driver, where it becomes this card's SELECT * widening. After PR #7617, this comment is the last place in the repo still asserting that dotted-path resolution exists — worth folding the comment correction (and reconsidering the head-only validation) into this card's fix rather than a separate one.

---

Generated by Claude Code

[os-zhuang]

Findings triage round, 2026-08-11 (maintainer-directed). Graded: hold — defence-in-depth behind #7532's ingress gate (PR #7588); once that lands, only registry-less internal callers can reach the widening ladder. Restart: #7532 merged AND any measured internal-caller path (hooks/flows/reports/expand) shown to carry an unresolvable projection.

---

Generated by Claude Code