rest: the record-share routes classify refusals by `message.startsWith(CODE)` and interpolate `error.message` into a hand-built 500 — a declared `status`/`code` is ignored and the sandbox wrapper reaches the client

[os-zhuang]

Filed unassigned while implementing #11588 (the sandbox debug wrapper on the bulk write routes). Out of scope there: #11588's table names six routes and this is a third branch again, with a different defect on top of the shared one.

Measured

packages/rest/src/rest-server.ts, the record-share family — GET/POST /api/v1/data/:object/:id/shares and DELETE …/shares/:shareId. All three catches are:

} catch (error: any) {
 if (respondSharingError(res, error)) return;
 logError('[REST] Grant share error:', error);
 respondError(res, 500, 'SHARE_GRANT_FAILED', String(error?.message ?? error).slice(0, 500));
}

and respondSharingError is:

const msg = String(error?.message ?? error ?? '');
const map: Array<[ErrorCode, number]> = [
 ['VALIDATION_FAILED', 400], ['PERMISSION_DENIED', 403], ['NOT_FOUND', 404],
 ['CONFLICT', 409], ['SHARING_NOT_ENABLED', 422],
];
for (const [code, status] of map) {
 if (msg.startsWith(code)) { respondError(res, status, code, msg.replace(...)); return true; }
}
return false;

Two independent problems, both on the same read of error.message:

1. A declared status / code is ignored entirely. These routes touch neither classifyDataError's unwrap door nor resolveErrorResponse's declared-status passthrough. A producer that throws Object.assign(new Error(msg), { code: 'RECORD_LOCKED', status: 409 }) — the ADR-0112 envelope every other /data face honours — is answered 500 SHARE_GRANT_FAILED, because 'RECORD_LOCKED' is not one of the five prefixes. This is the same "classification is a property of the message's wording" shape analytics 的 filter 拒收到不了调用方:service 侧多数拒收没有 ADR-0112 信封,REST 面又用 message 正则嗅探,一律答 500 #5352/analytics dataset 路由的 message 正则兜底没有退休时间表:六族拒收仍靠措辞分类,改一个字就换一个 HTTP 码 #5367 paid off on /analytics/dataset/query, still standing here.

2. The sandbox debug wrapper reaches the client, which is rest: the sandbox debug wrapper hook '<name>' threw: Error: … reaches the client on every write route that exits above mapDataError's unwrap (batch, createMany, updateMany, deleteMany, clone, analytics) #11588's defect on a branch rest: the sandbox debug wrapper hook '<name>' threw: Error: … reaches the client on every write route that exits above mapDataError's unwrap (batch, createMany, updateMany, deleteMany, clone, analytics) #11588 did not fix. A sandboxed hook refusal arrives with .message = hook '<name>' threw: Error: <business text> and .innerMessage = the business text. msg.startsWith(CODE) never matches (the wrapper is the prefix), so it falls to the 500 arm and the wrapper is interpolated verbatim.

Why it was not fixed in #11588

#11588's dispatch fenced the card to the six routes its table measured, and this family is not among them. It is also a larger repair than the message read: the right answer is almost certainly to route these three catches through handleRouteError like every other /data route, which changes their status/code answers, not just their prose — a behaviour change that deserves its own card and its own pins.

Not established here

• Whether any producer in the sharing service currently throws a declared code/status envelope, or whether all of them still use the CODE: message string convention these prefixes were written for. If the latter, problem 1 is latent rather than live — but the convention is the thing analytics dataset 路由的 message 正则兜底没有退休时间表:六族拒收仍靠措辞分类,改一个字就换一个 HTTP 码 #5367 removed elsewhere.
• Severity not judged.

Region: packages/rest/src/rest-server.ts, respondSharingError and the three share-route catches only.

[os-zhuang]

Triage: lands in packages/rest (record-share routes' refusal classification) → domain:cli, type Bug, pm:queue. Rationale: classifying by message.startsWith(CODE) while ignoring a declared status/code, and interpolating error.message into a hand-built 500, is the same declared≠enforced error-mapping defect class the route family already settled elsewhere — plus it leaks the sandbox wrapper to the client.

⚠️ Family / serial constraint: sibling of #11684 (analytics fallback arm, queued this round) and adjacent to in-flight #11588 (sandbox-wrapper leak above mapDataError, domain:cli). Fold-or-serial must-answer at claim time: these three describe one seam from three routes; the likely economical shape is one dispatch after #11588 lands, folded per the five gates with per-card acceptance criteria (each route's refusal maps status+code correctly, no wrapper text reaches the client).

---

Generated by Claude Code

[os-zhuang]

Claim — domain:cli lane execution seat, session 019siH5jDmk5hrayvfyojUqR, round R34.

Branch: claude/issue-11683-route-refusal-classification — shared with #11684 (see below).
Declared file surface: packages/rest/src/rest-server.ts (respondSharingError, the three share-route catches, and the /analytics/dataset/query catch), packages/rest/src/error-response.ts if handleRouteError needs a seam, + tests + a changeset.

Serial constraint discharged. Triage's constraint was "at minimum hard-serialize behind #11588 and re-measure on its merged ref". #11588 landed as #11687 (merged); the serial is released by the merge. The dev re-measures both routes on the current origin/main, because #11687 may have moved part of this gap.

Fold-or-serial, answered: FOLD with #11684. Both cards edit packages/rest/src/rest-server.ts, so they are a hard same-file serial in any case; folding is the cheaper of the two legal shapes here, and it is the shape triage proposed on both cards. The load-bearing reason is not file adjacency but that the two cards share one question: "what status does an undeclared hook refusal deserve on a route that is not /data?" Routing the share catches through handleRouteError (this card's suggested repair) answers it for the share family; #11684 asks it directly for the analytics family. Answering it twice, in two PRs, is how the two doors came to disagree in the first place.

Per-card acceptance criteria stay separate and are both required:

• rest: the record-share routes classify refusals by message.startsWith(CODE) and interpolate error.message into a hand-built 500 — a declared status/code is ignored and the sandbox wrapper reaches the client #11683 — each of the three share routes maps a declared status/code envelope (e.g. {code:'RECORD_LOCKED', status:409}) to that status and code; no sandbox wrapper text (hook '' threw: Error:) reaches the client on any of the three.
• rest: an UNDECLARED hook refusal answers 500 on /analytics/dataset/query where the same refusal answers 400 on /data — the route's fallback arm treats a business refusal as a server fault #11684 — an undeclared hook throw on POST /api/v1/analytics/dataset/query answers the same status as the same throw on POST /api/v1/data/:object. §8b of rest-hook-refusal-message-parity.test.ts currently pins the 500 as measured-and-wrong; that pin is inverted, not deleted, and its comment updated to say which door won.

⛔ Fork clause — binding on the fold. #11684's body names two candidate readings (ADR-0112's "the producer names the condition" ⇒ 500 is honest; the /data door's "a hook throw is a business rule" ⇒ 400 is honest). Establish which one the repo has already committed to, from its own pins and ADR text — classifyDataError's sandbox unwrap door and hook-error-format.dogfood.test.ts are the strongest in-repo evidence, and ADR-0112's own words govern. If both readings turn out to have live in-repo pins behind them, stop and report the fork back to this seat; ⛔ do not pick a direction, and ⛔ do not ship the half you are confident about while the fork is open — file the fork and land nothing on the analytics arm. The share half may still land alone in that case, with #11684 returned to pm:queue.

Clause ②: yes. Both halves change the status and/or code a shipped route answers with. Contract-review tier applies per the standing rule; the changeset must name, per route, the old answer and the new one.

---

Generated by Claude Code