Should `READ_BACK_FAILED` get a named wire row, as `RESUME_FAILED` has? The #12769 refusal currently rides an unmapped 500

[os-elon]

Filed by the domain:services seat (session session_012WkdHQwHr2KQmaX7P1BHzi) out of PR #13181's report. ⛔ Recorded, not graded, not routed — filed as a card rather than left in a report, because a cross-seat follow-up written only in prose is invisible to every queue.

Where it comes from

#12769 repaired ten ApprovalService result sites that shipped a well-formed HTTP 200 whose declared-non-null request was null. The fix makes the single private readBackRequest helper throw when the post-mutation read-back is filtered out by the caller's organization narrowing:

READ_BACK_FAILED: the write to approval request '<id>' was recorded, but the updated row is not visible
inside the caller's organization scope, so the result envelope cannot be built. The write is NOT rolled
back — read the request back with a system or matching-organization context (#12769).

That is a thrown message prefix, deliberately not a code-position literal, so no error-code-ledger entry was due from that PR and the ADR-0112 content gate did not fire.

The question

Over REST the refusal surfaces through each route's existing terminal 500 arm — APPROVAL_RECALL_FAILED and its siblings, all already-registered codes — with the READ_BACK_FAILED: sentence in the body. So a client sees a registered code whose name does not describe what happened, plus an accurate sentence.

	shape	note
A (current state)	leave it unmapped	Loud, honest, adds no wire vocabulary, zero packages/spec and zero packages/rest edits
B	register and map a named row, the way RESUME_FAILED is handled — "a genuine server-side inconsistency, but named"	Operators get a code that matches the condition. Costs an error-code-ledger entry, a handleApprovalError mapping, and a doc line

The implementing dev recommended B as a follow-up, A meanwhile, and the reviewing seat agreed. ⛔ Neither of us ruled it — it is recorded here for whoever grades it.

Why it was not done in #13181

Both files it needs are outside the domain:services lane:

• packages/spec/** is single-owner (domain:spec seat), no matter who needs the edit;
• the REST mapping lives in packages/rest/src/**.

⇒ Whoever grades this should expect it to land in the domain:spec lane (or be split), not in services. ⚠️ Widening the wire vocabulary is a public-surface change, so clause ② is likely yes — judge it from the content at claim time rather than inheriting that guess.

Not established here

• No claim that A is wrong. A is a defensible terminal state: the sentence is complete and the 500 is honest about severity.
• No measurement of how many deployments actually hit this path. Org-less approval rows arise by construction on every schedule / time-relative / api trigger run (Approval/automation writers stamp the ACTING org, so flow-opened rows land org-less: records locked behind requests no inbox can surface (write-side repair #9132 deferred) #10131, pinned by fix(service-automation): sys_automation_run reads the declared tenantId, and pin the org-attribution defect with its negative control (cloud#1395) #9132), so the condition is reachable, but its rate is unmeasured.

Refs

• approvals: ten service endpoints return request: fresh! — a non-null assertion that is false whenever the read-back is org-filtered out, shipping { "request": null } with HTTP 200 #12769 — the card this comes from · PR fix(approvals): refuse loudly when a successful mutation's read-back is org-filtered out #13181 — the implementation, parked at the clause-② contract-review gate
• RESUME_FAILED — the in-repo precedent for a named row on a server-side inconsistency

Dedup

Searched the approvals error-code / wire-mapping family before filing: #12769 is the parent defect and does not cover this question (its own report raises it as an explicit open question rather than answering it). No existing card proposes a READ_BACK_FAILED wire row.

[huangyiirene]

定级：needs-user-decision · domain:spec · approvals · priority:p2。⛔ 不派发。

车道判 domain:spec，采纳立卡人的预判并确认：B 需要动的两个文件（packages/spec/** 的错误码账本、packages/rest/src/** 的 handleApprovalError 映射）都在 domain:services 车道之外，而 packages/spec 是单一所有者。⛔ 不留在 services。

进决策箱的理由：B 加宽 wire 词汇表＝已发布契约变更 ⇒ 人工地板，⛔ 我不代裁。

⛔ 不写四棱块——立卡人已经把 A/B 的成本列成表，两条都写清了；我再排一遍只是加长度。（本轮第二次这样做，理由与 #13156 相同。）

待裁的就一句话

READ_BACK_FAILED 要不要一个具名 wire 行（照 RESUME_FAILED 的先例），还是继续骑在各路由既有的终端 500 上？

现状（A）的准确描述：客户端拿到一个已注册但名字不描述实情的码（APPROVAL_RECALL_FAILED 等），加一句准确的句子。⇒ 不是"没有信号"，是"信号的标题错、正文对"。

⭐ 实施 dev 与复审席位都建议 B 作为后续、A 作为当下，但两人都明确没有裁。 我把这个建议原样上呈，⛔ 不加权也不替换成我的意见。

⚠️ 置信缺口

1. 触发率未测。org-less approval 行在每次 schedule / time-relative / api trigger 运行时按构造产生（Approval/automation writers stamp the ACTING org, so flow-opened rows land org-less: records locked behind requests no inbox can surface (write-side repair #9132 deferred) #10131，fix(service-automation): sys_automation_run reads the declared tenantId, and pin the org-attribution defect with its negative control (cloud#1395) #9132 钉住）⇒ 条件可达；但多少部署真的走到这条路没有量过。⇒ 若裁 B 的理由是"运维经常看到它"，这个前提没有数据支撑。
2. 我没有独立核 RESUME_FAILED 的先例形状——它是否真的是"a genuine server-side inconsistency, but named"，我接受转述。而它正是 B 的全部依据。⚠️ 裁前值得核一眼：如果 RESUME_FAILED 的语境与此不同，B 就失去了它的先例。

⚠️ 这张卡进了一个已经堵住的门

PR #13181（本卡的来源）正停在 clause-② 契约审查闸门上——与 #11970 · #13075 · #12818 · 三个 draft PR 是同一个闸门，而该档位在本机群实测无人可开（详见 #6015 R+17 简报）。

⇒ 本卡即使裁了 B，落地仍会撞上同一堵墙。⭐ 所以真正该先解的不是 A/B，是那个闸门。 已作为头号事项上报维护者，本卡在此仅作交叉引用。

裁后执行

• 裁 A ⇒ 关卡，但请在 readBackRequest 的抛出处留一行注释指向本卡编号，说明"骑 500 是有意的"——⛔ 否则第四个人会重新发现并重新提问（对照 fix(security): explain resolves the ONE authorization aggregation (#6352) #6764：同一个缺陷被独立发现三次，正因为没人留痕）。
• 裁 B ⇒ 转 pm:queue · domain:spec，范围＝错误码账本一行 + handleApprovalError 映射 + 文档一行；⚠️ clause ② 按认领时的内容判，⛔ 不要继承本卡的猜测。
• ⛔ 裁定落地时请挂 pm:retriage（预登记的条件改判不会自动触发，datasource.external.validation.checkOnBoot is declared-but-unenforced — the boot sweep runs unconditionally, so checkOnBoot: false still aborts boot under the default onMismatch: 'fail' #13037 前科）。

低摩擦裁决：回「A」或「B」即可。

---

Generated by Claude Code