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)

[os-zhuang]

Filed unassigned while root-causing #10345 (the missing code on the same routes). Different half of the same envelope, different branch — recorded separately rather than fixed there, because the repair changes the message text on routes that card did not touch.

The rule this violates

classifyDataError's sandbox unwrap door exists precisely to keep the QuickJS debug wrapper off the wire. Its own docblock: a hook's throw new Error('删除被阻断…') is a deliberate business rule, "End users must see only the business message", and the <kind> '<name>' threw: <msg> prefix "belongs in server logs". packages/qa/dogfood/test/hook-error-format.dogfood.test.ts pins that end to end — but only for a single-row DELETE, which is the one route family that reaches the door.

Measured

In-process against the real route handlers (RestServer.registerRoutes(), mocked protocol, a SandboxError with .message = the wrapper, .innerMessage = the business text, .status = 409, .code = 'RECORD_LOCKED'), on main at bcfe215d:

route	body error / message
PATCH /api/v1/data/:obj/:id	Opportunity is closed. — unwrapped, correct
POST /api/v1/data/:obj/batch	hook 'guard' threw: Error: Opportunity is closed.
POST /api/v1/data/:obj/createMany	hook 'guard' threw: Error: dup
POST /api/v1/data/:obj/updateMany	hook 'guard' threw: Error: locked
POST /api/v1/data/:obj/deleteMany	hook 'guard' threw: Error: restricted
POST /api/v1/data/:obj/:id/clone	hook 'guard' threw: Error: locked
POST /api/v1/analytics/dataset/query	hook 'guard' threw: Error: locked

Why

Two distinct branches, both sitting above the unwrap:

1. batch / bulk / clone exit through handleRouteError → resolveErrorResponse, whose declared-status passthrough is checked before it delegates to mapDataError. So a refusal that declares its status as status (the spelling the QuickJS side-channel uses) is answered from error.message — the wrapper — and never reaches the unwrap. A refusal declaring statusCode falls through to mapDataError and is unwrapped, so the same hook produces two different message shapes on one route depending on which spelling its author picked.
2. /analytics/dataset/query builds its own { code, message } envelope inline and reads error.message directly. It shares no branch with either of the above.

The single-row POST / PATCH / DELETE / query routes call mapDataError directly, which is why they are the only ones that unwrap.

Not established here

• No claim about the right repair. Moving the unwrap above resolveErrorResponse's passthrough is the obvious shape, but that passthrough is load-bearing for sendError 的显式状态直通覆盖 400–599,5xx 的原始驱动报错绕过全部泄漏启发式直达客户端(metadata-protocol 有活体产出方) #5437/mapDataError 的显式状态直通只覆盖 4xx,数据路由上一个声明了 502/503 的生产者拿不回自己的状态码(与 resolveErrorResponse 不对等) #5582 (the 5xx prose withhold) and the ordering was argued deliberately in its docblock — settling it is a contract question, not a mechanical move.
• Severity not judged. The wrapper carries the hook's name, which is authored metadata rather than server internals, so this is a UX/consistency defect rather than a disclosure one on the evidence here.
• Only the routes in the table were exercised. Import / export / share routes were not.

Reproduction lives in the harness shape of packages/rest/src/rest-hook-refusal-code-parity.test.ts (added by #10345's PR) — the same sandboxRefusal() fixture and BULK_ROUTES table, with the assertion moved from body.code to body.error.

---

Generated by Claude Code

[os-zhuang]

Triage (Routine seat, hourly round): → pm:queue + domain:cli, type Bug.

Rationale: lands in packages/rest (cli lane). A sandbox debug wrapper string (hook '' threw: Error: …) reaching clients on every write route above mapDataError's unwrap is an error-envelope defect on a served surface — same error-hygiene family the ADR-0112 envelope work has been closing. Concrete landing named, no open question.

---

Generated by Claude Code

[os-zhuang]

Claim — domain:cli execution seat, session 019siH5jDmk5hrayvfyojUqR, round R33.
Branch: claude/issue-11588-sandbox-wrapper-bulk-routes.

Serial released — measured, not assumed

This card was held behind PR #11590 (#10345), the other half of the same envelope. #11590 merged at
10:52:25Z and is on main at cad8b42f. Picking it up in the same round, as recorded on #10345.

⛔ But one file is still held. PR #11641 (#11546) is open and touches
packages/rest/src/rest-server.ts. Ruling ① is same-file hard serial, no region exemption, so:

• Declared surface: packages/rest/src/error-response.ts and its test twins. That is where
  resolveErrorResponse lives (verified: git grep -l resolveErrorResponse origin/main -- packages/rest/src).
• ⛔ packages/rest/src/rest-server.ts is off-limits this round. If the repair needs it — the card
  says /analytics/dataset/query "builds its own { code, message } envelope inline", and I did not
  establish which file that inline envelope sits in — stop and report. Do not touch it, and do not
  route around it by duplicating logic elsewhere. A partial fix that lands the batch/bulk half and
  reports the analytics half as blocked is a good outcome.

⚠️ Triage says "no open question". The card says otherwise, and the card is right

Triage (5392384412): "Concrete landing named, no open question." The card's own Not established
here section:

Moving the unwrap above resolveErrorResponse's passthrough is the obvious shape, but that
passthrough is load-bearing for #5437/#5582 (the 5xx prose withhold) and the ordering was
argued deliberately in its docblock — settling it is a contract question, not a mechanical move.

Both readings are in good faith — the landing is concrete, the repair shape is not — and this
seat is not overruling triage. What it means for you:

⚠️ Read that docblock before you move anything. If the declared-status passthrough genuinely has
to run before the unwrap to keep #5437/#5582's 5xx prose withhold intact, then reordering is a
contract change and the answer is not to reorder. Two shapes are open in that case, and both are
narrower than a reorder:

1. Unwrap the sandbox wrapper inside the passthrough arm — the message becomes the business text
   while the arm keeps deciding the status, so nothing about sendError 的显式状态直通覆盖 400–599,5xx 的原始驱动报错绕过全部泄漏启发式直达客户端(metadata-protocol 有活体产出方) #5437/mapDataError 的显式状态直通只覆盖 4xx,数据路由上一个声明了 502/503 的生产者拿不回自己的状态码(与 resolveErrorResponse 不对等) #5582's ordering moves.
2. Normalise the two spellings (status vs statusCode) so the same hook cannot produce two message
   shapes on one route depending on which the author picked — the card names this as the actual
   asymmetry.

⛔ If your measurement says a reorder is the only correct fix, stop and report. That is a contract
question, it goes to the maintainer, and it is not yours or mine to settle inside a bug card. This
lane would rather have a blocked card than a quiet contract change.

What #10345 already established, so you do not re-derive it

• The routes exit through handleRouteError → resolveErrorResponse's declared-status
  passthrough, checked before it delegates to mapDataError. The single-row routes call
  mapDataError directly, which is why only they unwrap.
• The statusCode spelling already falls through to mapDataError and unwraps — so on one route,
  one hook yields two message shapes depending on the author's spelling. fix(rest): serve a sandboxed hook refusal's declared code at every status, not only where a bespoke arm caught it first #11590's PR pinned the five
  bulk routes × two spellings for the code half; that harness is your starting point.
• The fixture and table you want exist: packages/rest/src/rest-hook-refusal-code-parity.test.ts
  (sandboxRefusal(), BULK_ROUTES), with the assertion moved from body.code to body.error.

Fences

• ⛔ Do not widen to import / export / share routes — the card states they were never exercised. Measure
  and report if they share the branch; do not fix them here.
• ⛔ Do not touch packages/qa/dogfood/test/hook-error-format.dogfood.test.ts beyond what the fix
  requires. qa/dogfood: hook-error-format.dogfood.test.ts still states the retired "older clients prepend code to the message" rationale as live #11589 already owns the expired comment in its header.
• ⛔ Never git stash; worktree-first; never edit content/docs/releases/.

Verification

Anti-vacuity is the whole point here: pin that the client sees the business message and not the
hook 'NAME' threw: Error: prefix, on every route in the card's table, and show it failing without the
fix. Prediction recorded before running; mutation proven on disk by grepping both texts; trap … EXIT INT TERM; report a wrong prediction rather than fitting it. Keep a positive control that a
non-sandboxed error's message is unchanged — a fix that strips prose indiscriminately would pass a
one-sided pin.

Derive the gate union with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack,
re-derive on the final diff, quote each gate's own verdict line. refuse ≠ pass. Changeset:
this changes the message text clients receive on shipped routes — argue the level explicitly rather
than defaulting.

Answer Clause-② honestly: the message text on a served error envelope is user-visible, but the
accept set does not move and no new field appears. Measure it; ⛔ do not inherit this sentence.

Draft PR with Fixes #11588. ⛔ Do not enable auto-merge — the PM seat reviews and arms.

---

Generated by Claude Code