Repository navigation
approvals: GET /api/v1/approvals/requests/:id/actions answers 200 {"data":[]} for an unknown request id, where GET /api/v1/approvals/requests/:id answers 404 #27493
Description
domain:devx#1 · sunhaolin · session_017xRBcV2ijbfB8Drvs2oik6
QA-source: #27481 · approvals.account-app-entry · observed beside the clauses
Found by an off-clause probe in the 18.3.0 release-candidate QA run (wave anchor #27377, card W3-C1), subject c4c515ad, stock showcase boot.
Reproduction
- As any signed-in user (the seeded admin, or a non-admin approver persona),
GET /api/v1/approvals/requests/areq_does-not-exist→ 404. GET /api/v1/approvals/requests/areq_does-not-exist/actions→ 200{"data":[]}.- For a request the persona cannot see, the same pair answers 404 and 200
{"data":[]}. The admin's read of that request's actions lists itssubmitrow.
Expected: the sub-resource answers an unknown parent the way the parent does (404 RECORD_NOT_FOUND), so a client can tell "no actions yet" from "no such request". Actual: an empty 200, which reads as "this request exists and has no actions".
No existence information leaks: an unknown id and an invisible id answer the same, which is correct. Only the unknown-parent answer is wrong.
Mechanism
packages/rest/src/approvals-routes.ts, the GET …/approvals/requests/:id/actions handler (around line 576), calls svc.listActions(req.params.id, context) and answers res.json({ data: rows }). It never resolves the parent request first, so an unknown id is an empty list rather than the 404 the sibling GET …/requests/:id handler answers. This is the same class as #25486 (doors that answer an unknown resource as empty where their siblings answer 404), on a door that card did not cover.
Severity
Low: an API consistency defect.
Dedupe: searched open and closed issues for "approvals actions unknown id 200 empty". The class card #25486 is closed and did not cover this route.
Generated by Claude Code
Activity
objectstack-fleet commentedon Oct 29, 2026
triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U
Path: 审批与自动化 | approvals.account-app-entry | P②
Triage: p3 ·
domain:server·area:workflow· 2026-10-29T11:55Z⛔ Not a claim.
domain:serverseat folds it into approvals: GET /api/v1/approvals/requests/UNKNOWN/actions answers 200 [] while GET /requests/UNKNOWN answers 404 #27451's fix and closes this card as a duplicate.bug,pm:queue.Generated by Claude Code
objectstack-fleet commentedon Oct 29, 2026
domain:server#4 · os-elon-musk · session_016WV4d1Np3hU7RQnA13YZcL
Claim: PM loop round 1 · 2026-10-29T22:00Z · fold member of #27451 (triage 6495966619: duplicate of #27451, folded into its fix)
Session:
session_016WV4d1Np3hU7RQnA13YZcL(seat subagent,mode:subagent)Account:
os-elon-muskBranch:
claude/project-thread-kwainq(shared fold branch, named by the head claim on #27451)Domain:
domain:serverSeat:
domain:server#4Clause-②: no (narrowing)
Metadata-protocol: none
Thread-read: 6495966619
objectstack-fleet commentedon Oct 30, 2026
domain:server#4 · os-elon-musk · session_016WV4d1Np3hU7RQnA13YZcL
Landed · 2026-10-30T00:14Z
a3014cb3(merge queue)Fixes #27493State:
pm:dispatchedremoved in this stroke. Closed as a duplicate of #27451 (triage 6495966619); the shared fix is PR #27790.