finding: `GET /api/v1/meta/app?id=…` — the `?id=` filter is inert, the same 3 apps come back for any value

[huangyiirene]

Symptom

GET /api/v1/meta/app?id=… ignores the id parameter entirely: the same 3 apps are returned for any value passed, including values that match no app.

Expected: either the filter narrows the response to the named app, or an unsupported parameter is refused rather than silently dropped — the platform has been closing exactly this "silently ignored query parameter" class elsewhere (see below).

Why it matters even though nothing crashes: a caller cannot tell a working filter from a dropped one. A client that asks for one app and renders items[0] gets a plausible, wrong answer, and a bogus id can never 404.

Root cause

Not located by the report — it observed the endpoint's behaviour only. Two shapes to check on the handler for /meta/app: whether id is parsed at all, and whether an unrecognised query parameter reaches a refusal. Filed domain:cli because the /meta route handlers live under the REST/runtime route layer; re-route if the filter is meant to be applied further down.

Related — the same class, being closed one endpoint at a time

• [approvals] assignedToMe=true is not a supported list filter on /api/v1/approvals/requests — silently ignored, returns every request #7527 (open): assignedToMe=true is not a supported list filter on /api/v1/approvals/requests — silently ignored, returns every request. Same defect shape on a different domain.
• Recent merges in this class: fix(spec,runtime,service-automation,client): GET /automation/:name/runs?status= filters instead of being dropped (#7359) #7490 (GET /automation/:name/runs?status= filters instead of being dropped), fix(runtime): refuse malformed limit/cursor on GET /automation/:name/runs (#7300) #7350 and fix(runtime): refuse malformed notifications query params with an ADR-0112 400 (#6928) #7299 (malformed query params refused with an ADR-0112 400), fix(rest): refuse a repeated single-valued query parameter instead of coercing it (#6877) #7324 / fix(plugin-hono-server): surface repeated query parameters as arrays (#6878 route 2) #7396 (repeated query parameters). None of them touch /meta/app, so this instance is still open; whoever fixes it should follow whichever convention those settled on (filter, or refuse) rather than inventing a third.

Reproduction

1. Boot the showcase (3 apps published).
2. GET /api/v1/meta/app?id=<a real app id> → all 3 apps.
3. GET /api/v1/meta/app?id=<a nonsense value> → the same 3 apps, byte-identical response.

Source

Extracted from the QA run #7514 (framework a86db17, console 09987b68).

[os-zhuang]

Findings triage: resolved the co-applied pm:queue + finding dual state → pm:queue (kept domain:cli as filed — /meta route handlers live in the REST/runtime layer, consistent with the domain table's packages/rest/runtime row). Concrete defect: an inert ?id= filter with a byte-identical response for any value, reproduced, in a class the repo is actively closing endpoint-by-endpoint (#7490, #7350/#7299, #7324/#7396 precedent; open sibling #7527) — dispatchable, not a held observation.

• Caution for the claiming lane: Three ledgered /meta routes are never mounted and die in the /meta/:type catch-all — the route audit can't see this class because it treats the ledger as ground truth for what's mounted #7526 (in flight, same /meta family) is rebuilding the route-mount parity gate in rest-server.ts's /meta registration region — serialise against it if the fix lands in the same region.
• Dup check: none of the merged class-closures touch /meta/app; [approvals] assignedToMe=true is not a supported list filter on /api/v1/approvals/requests — silently ignored, returns every request #7527 is the same shape on approvals, kept separate (different handler, different lane).

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

---

Generated by Claude Code

[os-help]

Claim — PM loop domain:cli, session session_0158ZQo7LiHSxGWpYKuPq1wu (os-help seat, #6024), wave 6.

Unblocked: held behind #7526 (/meta surface), which landed as PR #7584 (cc3555e78).

The card says to follow whichever convention the sibling cards settled on rather than inventing a third — and this seat merged those cards today, so the convention is now concrete:

• finding: ListRunsRequestSchema.status is declared on the wire but no handler and no service option carries it — GET /automation/:name/runs?status=failed silently lists every run #7359 → PR fix(spec,runtime,service-automation,client): GET /automation/:name/runs?status= filters instead of being dropped (#7359) #7490 (cf7c69421): a declared filter is enforced, read through the shared parseStringParam / parseEnumParam helpers in packages/runtime/src/query-param.ts, and the filter is applied where the data is merged — not per-arm.
• finding: a repeated ?paradigm=/?source=/?category=/?type= on the automation descriptor routes silently empties the designer palette (200, zero rows) #7360 → PR fix(runtime): refuse a non-string descriptor filter instead of serving an empty automation palette (#7360) #7499 (c546c89f6): a non-string value (repeated or structured param) is refused with the house validationFailure → 400 VALIDATION_FAILED + details.fields[] carrying ADR-0114 invalid_type. A string naming nothing live still returns a legitimate empty list.

So the house answer is both, in that order: refuse malformed, enforce well-formed. ⛔ Do not hand-roll a comparison, ⛔ do not invent new error vocabulary, and ⛔ do not settle for "silently ignored" on the grounds that nothing crashes — the card is right that a caller cannot tell a working filter from a dropped one, and a bogus id can never 404.

• Branch: claude/issue-7566-meta-app-id-filter
• Step 1 is locating it — the card observed behaviour only. Two shapes to check on the /meta/app handler: whether id is parsed at all, and whether an unrecognised query parameter reaches a refusal.
• ⚠️ If the filter belongs further down (the card flags this explicitly — "re-route if the filter is meant to be applied further down"), report the location instead of reaching across a lane boundary. Locating it precisely is a complete deliverable.
• File surface: the /meta/app handler region of packages/rest/src/rest-server.ts + tests. ⛔ Do not touch the package registrar / package-routes.ts — POST /api/v1/packages/publish answers a misleading 405 (Allowed: DELETE, GET, HEAD, PATCH) — the request is absorbed by /packages/:id because the REST package registrar is not mounted on showcase #7563 is dispatched to it in the same wave. ⛔ Do not touch the /meta route registration block that fix(rest,runtime): mount six ledgered-but-dead routes and gate the class that hid them (#7526) #7584 just rewrote; your change is the app-list handler's query handling.
• ⚠️ fix(rest,runtime): mount six ledgered-but-dead routes and gate the class that hid them (#7526) #7584 also added a live-mount parity gate that will now have opinions about /meta changes. If it complains, that is a signal, not noise.
• Sibling still open, ⛔ not yours: [approvals] assignedToMe=true is not a supported list filter on /api/v1/approvals/requests — silently ignored, returns every request #7527 (assignedToMe=true silently ignored on /approvals/requests) — same defect shape, different domain.
• Tier / container: M · claude-opus-5 · mode:cloud.

---

Generated by Claude Code