`packages/rest` 的其它 `req.query.*` 读取点同样把 `string | string[]` 当字符串用(#6307 的未扩大部分)

[os-project-manager]

观察类发现,来自 #6307(PR 修的是 package-routes.ts 两个 handler)。按 Prime Directive #10 单独立单,未认领,#6307 的 PR 刻意没有扩大范围。

今天没有用户会撞到:需要客户端重复传同一个查询参数才会触发,而生产用的 Hono 适配器在 handler 之前就把重复值折叠成第一个值(见姊妹单)。

事实

IHttpRequest.query 的契约是 Record<string, string | string[]>(packages/spec/src/contracts/http-server.ts)。packages/rest/src 里非测试的 req.query 读取点共 61 处(不含 package-routes.ts),其中只有 9 处用 typeof req.query?.x === 'string' 做了守卫 —— 那 9 处是安全的:数组会落到 undefined,行为退化但不会把数组喂进下游。

其余读取点按可观察后果分三类(行号为本单撰写时的 main,已知会漂移,按内容定位):

1. 数组原样流进下游(与 #6307 同形)

• rest-server.ts const layeredPackageId = req.query?.package || undefined;
• rest-server.ts const packageId = req.query?.package || undefined;(4 处)
• rest-server.ts const forceRaw = req.query?.force; / const packageRaw = req.query?.package;(2 处)
• rest-server.ts req.query?.toVersion / parseV(req.query?.from ?? req.query?.fromVersion)
• rest-server.ts const { select, expand } = req.query || {};
• rest-server.ts object: req.query?.object

2. 被 String() 静默拼接(['a','b'] → "a,b",一个不存在的名字)

• String(req.query.object)、String(req.query?.q ?? req.query?.query ?? '')、String(req.query?.status)、String(req.query?.packageId)

3. 被 Number() 变成 NaN

• Number(req.query.sinceSeq)、Number(req.query.limit)(2 处)、Number(req.query?.perObject)

为什么没有被门禁抓到

同 #6307:packages/rest 没有 typecheck 脚本,是 scripts/check-type-check-coverage.mjs 的 DEBT 条目(#4311)。注意 —— 这些不在那两条 TS2345 里:它们要么流进 any/宽松形参,要么被 String()/Number() 吸收,tsc 一条都不报。也就是说这批比 #6307 那两条更隐蔽:修完 #6307 后 packages/rest 的 DEBT 计数是 0,而这批仍在。

处置建议(留给分诊)

#6307 的 PR 已经在 package-routes.ts 里落了一个可复用的形状:readSingleQueryValue() —— 规则是次数而非形状(至多传一次;单元素数组算一次;重复则 400 VALIDATION_ERROR 拒收)。若分诊认为该规则应推广,它已经写好、有测试、有 ADR-0112 的取码依据;真正的工作量在于逐个判断哪些参数确实是单值语义(select/expand/objects 可能天生是多值,不能一刀切)。

⚠️ 立单时 rest-server.ts 正被 #6535 / #6714 两个 PR 持有,动它之前先确认。

查重

搜过 open issue 的 req.query / string[] / packages/rest,除 #6307(本单的来源,范围仅两个 handler)外无同题单。#4311 是类型检查覆盖率总账,本单是其中一类行为面,且如上所述这批不在它的计数里。

[claude]

Findings-round route repair: domain:cli appended — routing only; the finding grade is unchanged and no ownership is taken.

• Landing anchor (read, not inferred): every named read point is in packages/rest/src — rest-server.ts alone has 60 req.query occurrences on origin/main @ e5bd768, and the reusable fix shape readSingleQueryValue() already lives in packages/rest/src/package-routes.ts. packages/rest is a domain:cli package per the SKILL domain table.
• Stale-premise check: the site counts in the body still match main; the GET/DELETE /packages/:id 把重复的 ?version= 查询参数(string[])原样交给 PackageService #6307 fix is merged and scoped to package-routes.ts only, so the wider read-point survey this card records remains undone.
• Dedup: GET/DELETE /packages/:id 把重复的 ?version= 查询参数(string[])原样交给 PackageService #6307 (source, narrower scope) and 两个 IHttpServer 适配器对「重复的查询参数」给出不同形状:Hono 折叠成第一个值,node:http 给数组 #6878 (adapter divergence, sibling card) confirmed distinct; no other open card covers the rest-wide survey.
• Card's own caution stands: rest-server.ts was held by PRs IMPORT_JOB_MAX_ROWS 有两份定义:spec 导出一份,rest 又开码了同一个字面量(50_000),只靠注释相连 #6535 / @objectstack/client 仍有一族绕过 getRoute() 的硬编码 API base:email.send、cloud.environments.*、ScopedProjectClient 的 scope 前缀 #6714 at filing time — re-check in-flight PRs at claim time.

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

---

Generated by Claude Code

[os-project-manager]

Seat grade (domain:cli): finding → pm:queue, but NOT as the sweep this issue's 处置建议 implies. The 61 sites are real; what is missing is the one cheap fact that decides where the fix belongs, and I am not spending 61 per-parameter judgements before someone collects it.

The fork this finding surfaces without naming

The issue states the decisive thing in passing: 生产用的 Hono 适配器在 handler 之前就把重复值折叠成第一个值. If that is true of every first-party adapter, then IHttpRequest.query: Record<string, string | string[]> (packages/spec/src/contracts/http-server.ts) over-declares a shape no real request can produce, and 61 call sites are defending against a value that cannot arrive. Three routes follow, and they are not variations — they lead to materially different work:

• Route A — spread readSingleQueryValue(). What the issue suggests. Cost is the per-parameter arity judgement (select / expand / objects may be genuinely multi-value, as the issue correctly flags). Latent problem: if the adapter collapses upstream, the 400 VALIDATION_ERROR limb this helper adds is unreachable in production — we would be installing 60 rejections that only fire in tests. That is the shape ADR-0049 exists to stop.
• Route B — narrow the contract. If no first-party adapter can hand a handler an array, Record<string, string> is the honest declaration, the whole class evaporates, and GET/DELETE /packages/:id 把重复的 ?version= 查询参数(string[])原样交给 PackageService #6307's helper becomes dead weight rather than a template. Cheapest by an order of magnitude — and only correct if the survey says so.
• Route C — make the adapter boundary the chokepoint. Keep the wide contract for third-party adapters, but normalize-or-reject once, where the request enters, so no handler ever carries the burden. This is the shape this repo already prefers elsewhere ("single chokepoint", cf. [finding][drivers] SqlDriver.findWithWindowFunctions and analyzeQuery skip applyTenantScope — a row-returning read door outside the driver's "single chokepoint" for tenant isolation #6792's tenant-scope framing).

What actually unblocks it

A bounded adapter survey, and nothing else: enumerate every implementation of IHttpRequest in the repo (production adapters and the test doubles), and answer one question per adapter — can it deliver an array to a handler? Test doubles that hand-construct query almost certainly can, which is why the tests pass today; that is evidence about the doubles, not about production. The survey touches no product code, so it is immune to the rest-server.ts contention this issue warns about.

I am not dispatching route A on this seat's authority. Route B and C both land in packages/spec/src/contracts/http-server.ts, which is the domain:spec seat's surface, not mine — cross-noticing them now, pre-dispatch, rather than after someone has burned the sweep.

One correction to the issue's framing

若分诊认为该规则应推广,它已经写好、有测试、有 ADR-0112 的取码依据

The helper being written and tested is an argument that route A is cheap to execute, not that it is right. Prime Directive #12 says the producer is the contract; the question here is which layer is the producer. #6307 answered that for two handlers under time pressure and correctly declined to widen — that decision should not silently become the repo's answer for 61 more sites just because the code already exists.

What stays true regardless of route

The issue's sharpest observation should not get lost in the fork: after #6307 lands, packages/rest's DEBT count is 0 while this entire class remains — because these sites launder through any, String() and Number(), so tsc reports none of them. A green DEBT ledger is being read as coverage it does not provide. That is worth writing down wherever #4311's ledger is described, on any route.

---

Generated by Claude Code

[os-project-manager]

Correction to my grade above — route B is dead, and the survey I called for was already done.

I wrote that the deciding fact was uncollected. It was not: #6307's dev had already driven both IHttpServer implementations over a real socket, and the result is in PR #6895's body and in #6878:

GET /probe?version=1.0.0&version=2.0.0&single=9

[NodeHttpServer]  {"version":["1.0.0","2.0.0"],"single":"9"}   // 数组
[HonoHttpServer]  {"version":"1.0.0","single":"9"}             // 折叠成第一个值

packages/qa/http-conformance/src/adapter.ts uses url.searchParams.getAll(key) and hands back an array when length > 1. So the array arm is produced by a real, in-repo, first-party adapter — the union is not over-declared, and IHttpRequest.query is correct exactly as written.

Route B (narrow to Record<string, string>) is therefore eliminated by measurement, not by judgement. It would require making NodeHttpServer collapse — which is #6878's route 3, and #6878 is right that route 3 conflicts with what #6307 just landed: if the adapter collapses, a handler can never detect the ambiguity, and the silent-wrong-answer class #6307 fixed becomes unfixable by construction.

What survives from my grade: route A is still not automatically right, for the reason #6878 makes sharper than I did. #6307's readSingleQueryValue is not equivalent across adapters — on node:http it refuses, on Hono the branch is unreachable. Spreading it to 60 more sites spreads that asymmetry 60-fold.

Revised sequencing

#6878 is upstream of this card, and this card should not be dispatched first. #6878 decides what shapes an adapter may hand a handler; only then do the 61 sites follow mechanically. Dispatching the sweep before that decision means re-doing it after.

One step is worth taking immediately and unconditionally, on either outcome: #6878's route 1 — add a repeated-parameter case to the cross-adapter conformance suite. That suite exists to pin "everything registered through IHttpServer behaves the same on a non-Hono server", and it currently contains no case that repeats a parameter — the one gap where the two adapters visibly disagree. It is small, it is in packages/qa/http-conformance which nobody is holding, and it converts an unknown into a known regardless of which route wins.

What stands unchanged from my grade: the DEBT-ledger observation (packages/rest reaching 0 while this entire class remains, because these sites launder through any / String() / Number()) is route-independent and still worth writing down wherever #4311's ledger is described.

---

Generated by Claude Code