[drivers] `InMemoryDriver.find` applies `limit` on truthiness, so `limit: 0` returns every row — the #6485 defect one layer below the client

[os-project-manager]

Found while implementing #6485 (PR to follow). Out of that issue's scope — its file surface was packages/client/src/index.ts only — so filed rather than fixed, per Prime Directive #10.

Fact (measured on origin/main @ 53ef05744, not read)

#6485's ruling was that limit: 0 means "return no records", and it required establishing that the server honours top=0 before shipping the client change. Measuring that turned up a driver that does not.

Probe run against each driver's real find, three rows in the table:

PROBE sql-driver    => {"limit0_rows":0,"limit2_rows":2,"noLimit_rows":3,"offset0_rows":3}
PROBE memory-driver => {"limit0_rows":3,"limit2_rows":2,"noLimit_rows":3}

SqlDriver returns 0 rows for limit: 0. InMemoryDriver returns 3 of 3 — the entire table, for a query that asked for none.

The cause is the same truthiness-vs-presence asymmetry #6485 named, one layer down:

• packages/drivers/driver-memory/src/memory-driver.ts:315 — if (query.limit) { results = results.slice(0, query.limit); }
• versus packages/drivers/driver-sql/src/sql-driver.ts:2773 — if (query.limit !== undefined) b.limit(query.limit);
• and packages/drivers/driver-turso/src/remote-transport.ts:1472 — if (query.limit !== undefined), also presence.

So two shipped drivers answer the same QueryAST with opposite result sets, and the one that disagrees is the one that returns more data than was requested rather than less.

Same shape, three more sites (unmeasured, listed by inspection)

Not probed, so stated as located rather than confirmed:

• packages/drivers/driver-sql/src/sql-driver.ts:3871 — findWithWindowFunctions, if (query.limit) builder.limit(query.limit). Truthiness, while findRows in the same file uses presence — so this driver disagrees with itself across two read doors.
• packages/drivers/driver-sql/src/sql-driver.ts:3911 — analyzeQuery / explain, same shape. A plan explained for a statement other than the one find would run.
• packages/drivers/driver-memory/src/memory-analytics.ts:434 and :598 — the $limit pipeline stage and the SQL string builder, both truthiness.

One that is NOT this bug, and should not be "fixed" into one

MongoDBDriver (packages/drivers/driver-mongodb/src/mongodb-driver.ts:231) already tests presence — if (query.limit !== undefined) findOptions.limit = query.limit; — but the MongoDB Node driver defines limit: 0 as no limit, so it returns every row too, for an unrelated reason. Aligning it needs a deliberate guard at that boundary, not the same edit. Worth a decision rather than a patch.

Why this is user-reachable now rather than theoretical

Before #6485 the client dropped limit: 0 on the floor, so no top=0 ever left the SDK and the divergence was unobservable through it. With that fixed, find('task', { limit: 0 }) puts top=0 on the wire, the protocol layer forwards limit: 0 to the engine (measured: findData neither rejects nor ignores it), and the answer now depends on which driver the deployment configured — zero rows on SQL/Turso, every row on memory.

Blocked-by: nothing; independent of #6485's PR, which is correct as it stands for the SQL/Turso path.

Not graded here

Severity judged at filing time is unreliable in both directions, so this is filed plainly and unassigned for the triage round. The two questions the grader will want: whether InMemoryDriver counts as a production surface (it backs LiteKernel, edge/serverless and most of the test suite), and whether the driver contract should state limit: 0 explicitly so the conformance suite can pin it — check:driver-conformance exists and passes today with the two drivers disagreeing.

[os-zhuang]

Triage: finding (held) + domain:drivers — routed and graded in one pass because the #5499 freeze decides the grade.

Anchors re-verified on origin/main @ a36db28 (main was force-updated since the card's ref 53ef057; secondary sites re-located by content): memory-driver.ts:315 and memory-analytics.ts:434/:598 truthiness — confirmed. sql-driver.ts:2773 presence on the main find door — confirmed. The two internal truthiness doors now sit at sql-driver.ts:3922 and :3962 (the card's :3871/:3911 drifted; locate by the if (query.limit) builder.limit(query.limit) pattern). mongodb-driver.ts:231 presence-with-driver-semantics — confirmed.

Why held rather than queued: the primary defect lands in driver-memory, which is under the maintainer's #5499 investment freeze; the standing rule there routes family cards but holds them, and mixed-face cards (this one spans memory + sql-internal + mongo) keep finding per the #5298/#5299/#5369 precedent. The freeze's restore-invariant exception (memory backend semantics corrupting CI verdicts) is not invoked: no test asserting limit: 0 semantics through the memory backend was demonstrated. Named trigger to escalate past the freeze: such a test surfaces, or a CI red traces to this divergence.

Two carve-outs recorded for later framing:

1. The unfrozen remainder is driver-sql disagreeing with itself (:3922/:3962 vs :2773) — a scoped internal-consistency fix the drivers lane may split out and queue without touching the frozen packages.
2. Reachability watch: once PR fix(client): data.find 的 top/skip 按存在性发射，limit: 0 不再被静默丢弃 (#6485) #6578 (the [finding][client] data.find's pagination params are emitted on truthiness, so { limit: 0 } is dropped exactly like the limit bug #6322 fixed #6485 client fix, currently draft) lands, limit: 0 goes on the wire and memory-backed (LiteKernel) deployments return every row for a query that asked for none. If the maintainer counts LiteKernel edge/serverless as a production face, this card graduates past the freeze — flagged in the round brief.

The MongoDB boundary (limit: 0 = no-limit in the driver itself) stays a deliberate-decision item, frozen with the rest.

Dedup: #6485 is the same asymmetry one layer up (client), explicitly out of this card's surface; PR #6578 implements it. No other limit: 0 card or PR in the three repos.

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

---

Generated by Claude Code

[qq9340100]

Findings triage round (2026-08-08, maintainer-directed sweep): promoted to pm:queue, added target:v17.

The hold's pre-registered graduation trigger fired: PR #6578 merged 2026-08-08T06:33Z, so find({ limit: 0 }) now emits top=0 on the wire and memory-backed deployments return every row — declared vs enforced against the #6485 ruling (limit 0 = no records), user-visible wrong data. driver-sql's internal inconsistency (presence-check at one site vs truthiness at two others in sql-driver.ts) is outside the #5499 freeze and fixable now; the memory-driver.ts:315 one-liner is inside the freeze. Dispatch should split: land the unfrozen driver-sql half first, and surface the freeze question on the memory half instead of silently flipping a frozen package. Internal line numbers drift — locate by pattern, not by line.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop, drivers lane (accelerated batch, maintainer-directed) — UNFROZEN HALF ONLY, per the triage split ruling (2026-08-08T10:22Z comment).
Session: session_01Hg9Pkg5nDedCRihRsdeCdX
Branch: claude/issue-6577-sql-limit-presence
Worktree: objectstack-issue-6577 (cloud session — own container)
Domain: domain:drivers
Scope of this dispatch: the driver-sql internal-consistency half (the two truthiness doors in sql-driver.ts, drifted to ~:3922/:3962, plus limit: 0 pinning for the unfrozen SQL-family drivers). The driver-memory one-liner and the MongoDB boundary stay OUT — #5499-frozen; the freeze question goes to the maintainer separately, not silently flipped here. The PR will say "Part of #6577", NOT "Fixes" — the issue stays open for the frozen half's ruling.
File surface: packages/drivers/driver-sql/src/sql-driver.ts (two if (query.limit) sites), driver-sql test files, possibly scripts/check-driver-conformance.mjs + the shared case-set if a limit: 0 conformance pin is added (with DEBT rows for the frozen drivers, not flips).
Serial constraints cleared: PR #6706 (issue #6518) touches sql-driver.ts and is IN THE MERGE QUEUE right now — this dispatch carries a hard precondition: do not branch until #6706's merge commit is on origin/main (verify by ancestry, not by memory). #6543 lands in unique-violation.ts (disjoint, per #6706's successor-repricing table). #6409/#6401 also touch sql-driver.ts and remain queued behind this one.

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling (2026-08-08 ~14:3xZ, chat) — the freeze question surfaced per the triage split is answered: A+ approved, verbatim: 「A+ 批准，按这个范围执行」.

Scope of the narrow #5499 freeze exception, exactly as put to the maintainer:

1. memory-driver.ts limit door truthiness → presence (one line) + the two same-shape sites in memory-analytics.ts ($limit stage, SQL string builder);
2. mongodb-driver.ts: explicit limit === 0 short-circuit guard returning an empty result BEFORE the upstream driver — the contract's semantics are not delegated to the MongoDB driver's own "0 = no limit" definition;
3. limit: 0 pinned in the shared driver conformance case-set across ALL FIVE drivers — no DEBT rows; future drift goes red at the gate;
4. The [裁决] driver-memory / driver-mongodb 投入冻结 —— 维护者 2026-08-05 口径（跨单锚点） #5499 freeze remains in force for everything else — the drivers(memory, mongodb): the $contains family still folds case — the last two backends left on the wrong side of #4706 Q2 = A #6682 case-folding programme and all other investment in driver-memory / driver-mongodb stay frozen. This exception is the limit door only.

Consequences: the in-flight dispatch (branch claude/issue-6577-sql-limit-presence, session_017qrJvYzSD5xhky5amXrnm2) is re-scoped to the full card; its PR says "Fixes #6577" (not "Part of") and closes this issue entirely, clearing it from the target:v17 board. File surface widens accordingly: + packages/drivers/driver-memory/src/memory-driver.ts, memory-analytics.ts, packages/drivers/driver-mongodb/src/mongodb-driver.ts, shared conformance case-set + scripts/check-driver-conformance.mjs, with changesets for the three touched driver packages.

---

Generated by Claude Code