The package door's 4xx paths still ship raw driver text — a returned failure never meets the 5xx withhold, and is mislabelled a client error

[hotlong]

Found while implementing #8086 (the 5xx message withhold on the same door, PR #8130). Recorded rather than acted on: #8086's ruling scoped the fix to 5xx messages only, and these are 4xx, so the sanitizer landing there deliberately does not touch them. Filed unassigned; nobody is on it.

The gap

#8086 closed the disclosure on sendThrownError — the exit a thrown error leaves by. Two other paths in the same registrar report failure by returning rather than throwing, so neither resolveThrownHttpError (#8016) nor the new withhold (#8086) ever sees them. Both answer 400 and both carry raw driver text.

1. POST /api/v1/packages/publish

packageService.publish swallows the driver error and hands the message back as data (packages/services/service-package/src/index.ts):

} catch (error) {
 logger.error('Failed to publish package', error as Error);
 return { success: false, error: (error as Error).message };
}

and the handler puts it straight on the wire (packages/rest/src/package-routes.ts):

sendError(res, 400, 'PACKAGE_PUBLISH_FAILED', result.error ?? `Failed to publish ${manifest.id}.`);

The statement being run is INSERT INTO sys_packages (...) ON CONFLICT(id, version) DO UPDATE SET ..., so a driver failure there produces exactly the family of text #3867's predicate exists to withhold — a constraint dump naming sys_packages and its columns, or a SQLITE_ERROR / SQLSTATE line.

Two defects, not one. The disclosure is the obvious half. The other is that a driver fault is being reported as 400 — a client error, inviting the caller to fix a request that was never the problem, and hiding a real server fault from every dashboard that buckets by status. This is precisely the class #8016 fixed for the throw path (a caller who was refused was told the platform had broken), in mirror image: here the platform breaks and the caller is told they made a mistake.

2. DELETE /api/v1/packages/:id — the partial-failure detail

protocol.deletePackage collects per-item failures with their raw messages:

} catch (e: any) {
 failed.push({ type: row.type, name: row.name, error: e?.message ?? 'delete failed', ... });
}

and the handler ships that array as structured detail on a 400:

sendError(res, 400, 'PACKAGE_DELETE_PARTIAL',
 `Deleting ${packageId} left ${result.failedCount} item(s) behind.`,
 { details: { failed: result.failed, cleanups: result.cleanups } });

Each failed[].error is whatever deleteMetaItem threw — including its Failed to delete customization overlay: ${err.message} re-wrap, which interpolates the driver line. Note this leaks through details, not message, so even a message-level withhold at this door would not reach it.

Why this is not just "extend #8086 to 4xx"

It must not be. A 4xx message is caller-facing by design and #8086's PR pins that on purpose — the protocol's [tenant_scope_required] refusal names the exact parameter to pass, a 409 DESTRUCTIVE_CHANGE names the remedy. Blanket-sanitizing 4xx would destroy the self-correcting messages #4277 exists for.

The honest fixes are the other two:

• Classify correctly. A driver fault surfacing through publish is a 5xx, and once it is, the The direct-mount package door ships 5xx messages verbatim — no leak heuristic, unlike the dispatcher twin and unlike rest-server's own /data exit #8086 withhold covers it with no new rule. This is the contract-first reading: the status is wrong, and the disclosure is downstream of the wrong status.
• Fix at the producer — the option C of The direct-mount package door ships 5xx messages verbatim — no leak heuristic, unlike the dispatcher twin and unlike rest-server's own /data exit #8086. service-package returning (error as Error).message as a caller-visible string is the same producer-side defect as metadata-protocol interpolating driver text, and it wants the same remedy: the driver text goes to the log (it already does — logger.error is right there), and the caller gets a stable sentence.

Evidence

Read from code, with the reachability of the sibling 5xx path measured. The #8086 reproduction drove a throwing publish through this handler (confirming the catch-all exit), and separately walked a real ObjectQL engine + real ObjectStackProtocolImplementation failure through DELETE, capturing the driver line on the wire. What was NOT driven end to end is the real service-package publish catch above — its return-shaped path is read from source, not reproduced. Whoever takes this should force an INSERT INTO sys_packages failure and record the actual 400 body before fixing, the same way #8086 was made to earn its premise.

[hotlong]

Triage: lands in domain:services, queued (pm:queue), type Bug, security (raw driver text disclosure).

Rationale: both defects are producer-side in packages/services/service-package — (a) publish swallowing a driver error and returning (error as Error).message as caller-visible data, (b) a driver fault answered as 400. The fix direction the card itself argues, adopted: classify correctly (driver fault through publish is a 5xx, which the existing #8086 withhold then covers with no new rule) + stop interpolating driver text at the producer (stable sentence to the caller, raw text to logs — it is already logged). The DELETE partial-failure details.failed[].error array needs the same producer-side treatment since no message-level withhold reaches details.

Scope guard from the card, kept binding: ⛔ do not blanket-sanitize 4xx — self-correcting caller-facing messages (#4277 class) are load-bearing. Sibling cards to read together at dispatch: #8136 (metadata-protocol producer sweep, separate card in domain:metadata) and #8132 (predicate gap, domain:cli). File surfaces are disjoint (service-package + package-routes here; metadata-protocol there; packages/types for #8132) so they can run in parallel, but each dispatch order should name the others as in-flight.

Dispatch precondition per the card's own honesty note: force a real INSERT INTO sys_packages failure and record the actual 400 body before fixing.

Size/model suggestion: M, opus.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 12
Session: session_01ARidKDYSCD56LaygrvDPnk
Branch: claude/issue-8131-package-door-producer-classify
Worktree: objectstack-issue-8131
Domain: domain:services
File surface: packages/services/service-package/src/**, packages/rest/src/package-routes.ts (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: no in-flight claim touches service-package or package-routes.ts. Sibling cards named by triage are file-disjoint and in other lanes — #8136 (metadata-protocol, domain:metadata), #8132 (packages/types, domain:cli); neither is claimed in this lane. This lane's other two dispatches this round (#8026 → service-settings, #8103 → service-settings/sys_secret read path) do not intersect this surface.

Note on the surface: packages/rest/src/package-routes.ts is nominally domain:cli territory, but the status reclassification (driver fault → 5xx) cannot be done producer-side alone. Triage's own rationale adopted that direction and declared the file surface, so this is dispatched as declared rather than re-routed. If the fix turns out to require behaviour changes inside packages/rest beyond the status/sendError call for these two handlers, that is a breach — stop and report.

---

Generated by Claude Code