[finding] after the #13279 repair, an UNRESOLVABLE data engine still answers 403 FORBIDDEN — the last surviving GRANTS-LOST disguise at the package door

[claude]

Found while implementing the #13279 ruling (PR #13475). No severity is asserted here; this records what was driven and what came back, for triage.

The shape

#13279 ruled that a permission-store READ FAILURE must fail loud, and tryFind now raises AuthzStoreUnavailableError (503 SERVICE_UNAVAILABLE) when a read is issued and throws. That repair does NOT reach a second path to the same disguise, because that path never issues a read at all.

rest-server.ts resolves the data engine as an absorbed rejection:

  const ql = kernel
      ? await kernel.getServiceAsync('objectql').catch(NO_OP_RETURNING_UNDEFINED)
      : ...;

So an engine that cannot be RESOLVED becomes ql === undefined. resolveAuthzContext then takes tryFind's guard for an unwired engine and returns an empty grant set — correctly, for its own contract: "no engine is wired" is a legitimate embedder shape and must stay quiet.

The two conditions are not the same fact, and they arrive at the resolver as the same value:

• an embedder that never configured a data plane — zero capabilities is TRUE;
• a deployment whose engine resolution FAILED — zero capabilities is UNKNOWN.

What was measured

Real RestServer, real registerPackageRoutes, wired as rest-api-plugin.ts wires it. Fault class DATA_ENGINE_UNRESOLVABLE in packages/rest/src/package-door-execctx-fault-reachability.test.ts.

wiring	GET /api/v1/packages
healthy store granting the capabilities	200
permission store reachable, every read throws	503 SERVICE_UNAVAILABLE (after #13279)
the data engine cannot be resolved at all	403 FORBIDDEN, unchanged

The third row still answers "Reading packages requires the studio.access or setup.access capability." to an authenticated administrator whose engine is simply gone. After #13279 it is the LAST surviving member of the GRANTS-LOST disguise on this door, and the inverted test in PR #13475 asserts that residue explicitly rather than leaving it to be rediscovered.

Why this was not folded into #13279

The #13279 ruling names tryFind / resolveUserAuthzGrants as its landing point and speaks of the permission store being unreachable. This seam is neither: it is the TRANSPORT's engine-resolution .catch, one layer out, and the correct behaviour there is a judgement rather than a mechanical consequence of that ruling — quieting it wrongly would refuse service to every embedder with no data plane, which is a supported configuration.

Related, and distinct

• [finding] a permission-store read failure resolves as an AUTHENTICATED caller holding ZERO capabilities — the package door answers 403 FORBIDDEN, byte-identical to a genuine capability denial #13279 — the read-failure half, ruled and implemented.
• [finding] resolveExecCtx 的 .catch(() => undefined) 把执行上下文解析失败静默降级为「无上下文」— 该行为在包管理门上可达什么错误状态,未测 #13255 — the CONTEXT-LOST degrade, whose answer is 401.
• [finding] at a RestServer provider seam a SYNCHRONOUS throw loses the whole execution context while an async rejection is absorbed — same fault, two different wire answers #13280 — the SYNCHRONOUS vs asynchronous provider-throw asymmetry. That card is about which throws reach the seam .catch; this one is about what an ABSORBED engine rejection then produces downstream.

None of those is addressed by this card, and this card is not addressed by any of them.

---

Generated by Claude Code

[claude]

分诊定级 · 首次定级 · bug · p2 · domain:cli · pm:queue

⚠️ 本卡此前只带 pm:retriage 一个标签。那是标签误用:pm:retriage 的语义是「已定级、但需重新定级」——它是对一次已有裁定的异议,按维护者 2026-08-19/20 裁决(「同意 并存」)必须与卡的常设 pm:* 并存。孤悬时 H18 的判词是**「异议对象不明」**,而本卡从未被定过级,⇒ 没有可异议的对象。本轮按 H18 的处方「resolve the grade (keep or change) and drop the label in the same write」一次写完。

域锚定(⛔ 不按标题猜)

修法落在 packages/rest/src/rest-server.ts 那处 .catch(NO_OP_RETURNING_UNDEFINED) 吸收面。按车道表 packages/rest 归 domain:cli(references/lanes/engine.md:15 与 spec.md:27 两处同述)。标题里的 403 / GRANTS-LOST 会把人引向 identity,⛔ 那是标题的形状,不是修法的落点。

为什么 p2 而不是 p1

方向是保守的。 未知(引擎无法解析)被答成 403 拒绝,不是被答成 200 放行 ⇒ 没有越权面。损伤是诊断面与运维面:一个解析失败的数据引擎在门上自称「你没有权限」,而真相是「无法判断」。

为什么仍然入队而不是持有

它是 #13279 已裁类的最后一个存活实例。类已经裁过(读失败必须响亮失败),剩下的是覆盖面而不是取舍 ⇒ 无需再入决策箱。

范围钉死

• 只治「解析失败 ≠ 未接线」这一处二义;⛔ 不重开 [finding] a permission-store read failure resolves as an AUTHENTICATED caller holding ZERO capabilities — the package door answers 403 FORBIDDEN, byte-identical to a genuine capability denial #13279 的 503 口径,也不改「未接线时保持安静」那条(卡自己已确认那是合法的 embedder 形状)。
• 必答项:NO_OP_RETURNING_UNDEFINED 是否还有第三个消费方把这两种事实读成同一个值 —— 若有,本单范围内一并点名,⛔ 但不顺手改,另立单。

---

Generated by Claude Code