Repository navigation
[finding] errorResponseBase 文件头是 error.details.code 漂移的第四处 —— #6123 修了三处,dispatcher-plugin.ts:467 因红线未动 #6270
Description
Activity
Triage (lane repair):
domain:runtime→domain:cli. Grade unchanged (finding, held).domain:runtimeis not in the SKILL domain table and nopm:seatpost owns it — it was an orphan lane carrying exactly one open issue repo-wide, which means this finding had no seat that could ever grade or take it.packages/runtimebelongs todomain:cliper the table (cli / runtime / verify / qa / types / rest / mcp / observability / client / …), and the landing site here ispackages/runtime/src/dispatcher-plugin.ts:467-:469with the corroborating read inpackages/runtime/src/error-envelope.ts:112-:124. Same package, same lane.Grade stays
finding— nothing in the substance changed, and it is observation-class as filed: the drift is in a doc block, the wire behaviour is already correct and already pinned byanalytics-query-read-scope-withhold.test.ts:218. No user hits it today; what it costs is the next reader of that comment believingdetails.codereaches the client when the envelope has hoisted it into a declared field and droppeddetailsentirely.Note for the cli lane when this is graded: #6123 fixed three sites of this same sentence and drew an explicit ⛔ line around
dispatcher-plugin.ts, so this is the deliberate remainder, not an oversight — and it is a text-only fix in a lane whose other work is not.本评论来自分诊座位 Routine(#5474 试点),不构成认领。
Generated by Claude Code
Findings sweep (maintainer-authorized one-off, 2026-08-07 — registered on #6015): promoted to the queue. Fourth site of the prose drift #6123 fixed at three, excluded from that PR only by its scope red-line — a two-line comment correction, sweep-packageable with other text fixes in the cli lane.
finding→pm:queue.
Generated by Claude Code
认领:开始实施(第四处
error.details.code文案漂移,dispatcher-plugin.ts:467-:469,comments-only)。- session:
session_017uFVNMmTxLpmfQYiuKM1Yx - branch:
claude/issue-6270-error-response-base-doc-drift - worktree base:
origin/main@25ab57bd5
措辞将对齐 PR #6264 在另外三处落的同一句(
error.code/splitSemanticCode提升 /details键整体消失),并给:452-:457的 JSON 示例补时态说明。零行为改动。
Generated by Claude Code
- session:
ACCEPT — PR #6912 复核通过,已翻 ready + 挂 auto-merge。25 个 check run 全 success/skipped,零失败(本席自查 GitHub,非采信 dev 报告)。
这张卡的验收标准与代码卡不同 —— 它是观察类、零行为变更,没有红可制造。所以复核看的是三件事,三件都过:
① 没有伪造覆盖。 dev 明写「NO RED WAS MANUFACTURED, and none exists to manufacture」,并说明理由:零行为改动 ⇒ 注释没有失败态 ⇒ 硬造一个 red 只会是伪证。这正是本车道 #6536 / #6316 / #6643 一路执行的口径。
② 新措辞为真的证据是既有锚点,不是新断言。
analytics-query-read-scope-withhold.test.ts:218(真AnalyticsService+ 真挂载路由)expect(res.body.error.code).toBe('READ_SCOPE_COMPILE_FAILED')。关键在于 dev 发现该测试:211-:217的注释早就把这件事说对了 —— 也就是说本 PR 是把 doc block 对齐到测试先钉住的事实,不主张任何新事实。这是这类卡最强的证据形态。③ 措辞是第四处同一句话,不是第四种说法。 复用 PR #6264 的骨架(
⚠️ At error.code — NOT error.details.code/only STAGES/PROMOTES/returns the now-empty details as undefined/never present to read/ 实测 body /Pinned end-to-end in …),只改「谁在暂存」的主语 —— #6264 说errorResponseBaseonly STAGES,在errorResponseBase自己内部这么写很怪,故改为 thedetailsassembly below (#3842) only STAGES。两处 dev 的自主判断,本席认可
JSON 示例:判了,没瞎改。 派发令要求「若它已经是明确过去时就别动,并说明」。dev 核完认定不是:领头句 “It never saw … and those messages name …” 是现在时,fence 里的
→ 500 {…}读起来像实况,而且它的形状是对的(code直接挂在error下)—— 恰恰因为形状对,才最容易被当成今天的线上形态。于是加两行⚠️ PAST TENSE标注、保留示例(它在做「这条[#5811]条目关掉了什么」的正经工作),并把标注放在 fence 内部,理由是读者眼睛会直接跳进 fence、外面的引导句会被跳过。判断与理由都成立。⚠️ 它主动丢掉了 #6264 引的行号,这条值得全仓注意。 #6264 的措辞里引了error-envelope.ts:117,而今天main上:117是buildApiError,splitSemanticCode在:100—— 那个引用已经漂了。dev 因此在本站点只写./error-envelope.ts不带行号。这是对的:本仓行号漂移是常态(卡片正文一律「按内容定位」),在散文里钉行号等于给自己造下一处漂移。本席不为此另立卡 —— 一个漂掉的行号不值一张卡,而且 #6264 那三处的实质结论仍然正确;记在这里供后来者。第五处:没有。 全仓扫过
details.code,http-dispatcher.ts×3、error-envelope.ts、domain-handler-registry.ts、packages/client都已正确描述为「被buildApiError提升进error.code的载体」—— 那是这句话为真的那一半,不是漂移。CHANGELOG 属已发布记录,不动。changeset 判
patch且不走空 frontmatter,理由正确:scripts/check-empty-changeset.mjs明令拒收新增的空 changeset(#5471/#4898 —— 空 changeset 是changesets/action的真实输入,会静默卡住发布)。
Generated by Claude Code
观察(observation-class,今天没有用户会撞到)
实施 #6123(PR #6264)时发现:同一句「
err.code落在details.code」的说法还有第四处,在errorResponseBase自己的文件头里。#6123 的分诊把范围钉死为三处(#5367 的 changeset、read-scope-sql.ts文件头、#5811 正文),并明文划了 ⛔ 不动dispatcher-plugin.ts的红线,所以按 PD #10 只记录不修。位置与原文
packages/runtime/src/dispatcher-plugin.ts:467-:469(实测于origin/main@f6609e6ae,行号仍然是 467):为什么这也是漂移
括号里的
(#3842, below)指的是同函数下方:510-:513那段const details = …的本地暂存,这半句没错。错的是后半句的两个断言:READ_SCOPE_COMPILE_FAILEDto the client」两句都在讲线上位置,而线上位置不是
details.code。:516把这个details交给buildApiError(packages/runtime/src/error-envelope.ts:117),splitSemanticCode取走code提升进声明字段,rest为空于是返回details: undefined(error-envelope.ts:112),:124的条件展开被跳过 ——details键整个消失。机器实际读到的是:{"success":false,"error":{"code":"READ_SCOPE_COMPILE_FAILED", "message":"Internal server error","httpStatus":500}}已由
packages/runtime/src/analytics-query-read-scope-withhold.test.ts:218(真AnalyticsService+ 真挂载路由)钉住。为什么单独立单而不是搭 #6264 的车
errorResponseBase的err.code落在error.code而非error.details.code—— #5367 changeset 与 read-scope-sql.ts 文件头都把线上位置写错了 #6123 的分诊评论把范围枚举为 three sites,并明确dispatcher-plugin.ts是只读参考面;派工单同样把它列为红线。把第四处塞进那个 PR 会越过一条明写的边界。errorResponseBase的人 —— 他就站在做暂存的那个函数里,读到「details.code carries it to the client」会直接把本地变量名当成线上契约。方向上比前三处更容易误导,尽管触达面更窄。为什么按 observation-class 归档(不预判优先级)
errorResponseBase的err.code落在error.code而非error.details.code—— #5367 changeset 与 read-scope-sql.ts 文件头都把线上位置写错了 #6123 的 changeset 那样会随CHANGELOG.md发到 npm。建议动作(一行注释)
把
:467-:469改成error.code,并补一句提升机制 —— 与 PR #6264 给另外两处补的措辞保持一致即可。顺带值得一并核::452-:457那段 JSON 示例展示的是{"error":{"message":…,"code":…}}(code 直接挂在error下),形状其实是对的,但它描述的是 #5811 修复之前的泄漏状态,与:467那句并排读容易混淆,可在同一次修里加一句时态说明。参考
packages/runtime/src/dispatcher-plugin.ts:467-:469(本单)、:510-:517(details组装与buildApiError调用)packages/runtime/src/error-envelope.ts:117(buildApiError)、:112(splitSemanticCode返回undefined的那一行)packages/runtime/src/analytics-query-read-scope-withhold.test.ts:218(实测锚点)errorResponseBase的err.code落在error.code而非error.details.code—— #5367 changeset 与 read-scope-sql.ts 文件头都把线上位置写错了 #6123 / PR docs(analytics):err.code的线上落点是error.code,不是error.details.code(#6123) #6264(前三处的更正)、/analytics/query仍把 RLS 策略字段名回显给调用方 —— read-scope 拒收的泄漏在姐妹面上没堵,#5367 只堵了 dataset 路由 #5811(第三处所在)、The dispatcher puts the HTTP status inerror.codeand parks the real code indetails— pinned in #3687, still unfixed #3842(提升机制的出处)会话:
session_015a5qkLzpGXhLL2F5gvJ7dD