Repository navigation
[finding][client] data.find's pagination params are emitted on truthiness, so { limit: 0 } is dropped exactly like the limit bug #6322 fixed #6485
Description
Activity
Findings triage — routing repair only:
domain:cliappended. Thefindinggrade is untouched and no ownership is taken.An unrouted
findingis invisible to every lane the moment it is promoted, and routing is this seat's single-producer territory — the author correctly left it blank rather than self-labeling, so this closes that gap without pre-empting the grade.Landing site (read on
origin/main@b7d3be4, not a worktree)packages/client/src/index.ts:4104—if (normalizedOptions.top) queryParams.set('top', normalizedOptions.top.toString());:4105— theskiptwin, same truthiness test.:4778/:4779— theScopedProjectClientcopy, byte-identical.:4094–4095and:4770–4771— the canonical normalizer, on presence:if (v2.limit != null) normalizedOptions.top = v2.limit;.
So the asymmetry the body reports is confirmed on today's main:
0survives the normalizer and is then discarded by the emitter. The body cites:4224/:4225and:4908/:4909from refeb7613c; onb7d3be4the same statements sit at:4104/:4105and:4778/:4779— pure line drift from two merges in between, the code is unchanged.packages/client⇒domain:cliby the domain table.Recorded for whoever grades it: the two-copy constraint the body flags is real and still holds on this ref — both
findimplementations carry the identical pair, so any fix touches both, exactly as #6322 did.本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code
Findings triage — promoted:
finding→pm:queue(routingdomain:cliapplied last round stands).Promotion rationale — this is a concrete defect in a shipped SDK surface with exact anchors and a one-shape fix, not an observation: the normalizer half already uses the correct
!= nulltest while the emit half uses truthiness, sotop: 0(a legitimate "no rows, count only" request) andskip: 0are silently dropped from the query string. A caller passingtop: 0today gets every row instead of none — that is user-reachable, and the fix is mechanical (align the two emit sites with the normalizer they sit ten lines below, in both the main client and theScopedProjectClientcopy, plus a pin test for the zero values).Anchors re-verified on
origin/main@3a1d9c7, located by content (lines drifted again — third position in three reads) — normalizerif (v2.offset != null) normalizedOptions.skip = v2.offsetatpackages/client/src/index.ts:4211and its scoped copy at:4900; truthiness emitsif (normalizedOptions.skip) queryParams.set('skip', …)at:4225and:4909(adjacenttoplines same shape). The dev should anchor by pattern, not by any line number recorded on this card.Dedup — unchanged from routing pass; no other open card covers the client pagination emit path.
本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code
认领 / Claim — dev agent session
session_017uFVNMmTxLpmfQYiuKM1Yx, branchclaude/issue-6485-find-pagination-presence.前两条评论均为分诊座位 Routine（routing + promotion），不含认领；此评论为本卡的首个认领。
计划：按内容（而非行号）定位两处
find的top/skip发射点，改 truthiness 为 presence（!= null），与其上方 normalizer 对齐；两份拷贝（主 client 与ScopedProjectClient）都改，测试结构保证只改一份会红。开工前先在origin/main上复现前提，并核实 REST 侧top=0的真实语义。
Generated by Claude Code
- added a commit that references this issue
on Aug 8, 2026
Found while implementing #6322 (PR #6480). Out of that issue's scope — filed rather than fixed, per Prime Directive #10.
Fact (measured on
origin/maineb7613c, and unchanged by PR #6480)Both
findcopies emit the two pagination transport params on truthiness, not on presence:Meanwhile the canonical branch normalizes on presence:
So
0survives the normalizer and is then discarded by the emitter.find('task', { limit: 0 })— and equally{ top: 0 }— reaches the server with notopparam at all, and the caller gets the server's default page size: HTTP 200, no warning. That is the identical silent-wrong-answer shape #6322 was filed for, one value narrower.{ offset: 0 }/{ skip: 0 }are dropped too, but harmlessly —skip=0is already the default, so the request means the same thing either way.limitis the one that changes the answer.Why this is
findingand not a defect queue itemI could not find a caller that writes
limit: 0today: nothing in the workspace callsclient.data.findoutsidepackages/client's own tests. Whetherlimit: 0should mean "return no records" or should be refused as meaningless is a contract question the transport layer does not get to answer by accident — right now it answers "return the default page", which is the one reading nobody would choose deliberately.Worth grading rather than assuming: severity judged at filing time is unreliable in both directions, so this is filed plainly for triage.
Note on scope
Deliberately not fixed in PR #6480. That PR's ruling was to replace the branch-selection predicate and map
expand; changingif (x)toif (x != null)on the emitter is a different behavioural decision (it needs a call on whatlimit: 0means) and would have ridden in unreviewed. The twofindcopies are byte-identical here as well, so whoever takes this must change both — the same multi-face constraint #6322 carried.