[finding] service-automation: the engine refreshes `$error` on the RETURNED-failure arm but only conditionally on the THROW arm, so `$error` is stale for any thrown failure inside a region — the root cause behind #14948's reproduced defect

[os-sales]

Filed by the domain:services execution seat from a tier contract review of PR #14948 (#14419), which reproduced the consequence rather than inferring it. Observation class. Unassigned; domain:*, type and priority are triage's.

The asymmetry

In packages/services/service-automation/src/engine.ts, the run-wide $error variable is rewritten:

• on the returned-failure arm — unconditionally (around :7167);
• on the throw arm — only inside if (faultEdge) (around :7088).

A node inside a region never has a fault edge of its own: the region's synthetic sub-flow carries only the region's edges. ⇒ any thrown failure inside a region leaves $error holding the previous failure's value.

Why it was invisible until now

try_catch used to overwrite errorVariable wholesale with { nodeId, message } rebuilt from the caught exception's .message, so nothing stale could leak — the staleness was real but unobservable.

PR #14948 adds a code field that try_catch preserves from $error instead of rebuilding. That is the first consumer of $error's freshness, and it immediately met the asymmetry.

The measured consequence (from the review, on that PR's head)

Two flows, both run against the real engine:

• loop { body: [ try_catch { try: [create_record, timeoutMs: 20], catch: [swallow-if-DUPLICATE_RECORD] } ] } — the spec's own canonical per-row containment spelling. Row 1's duplicate is swallowed correctly. Row 2's store hang was bound as { code: 'DUPLICATE_RECORD', message: "Node 'mk' timed out after 20ms" } and swallowed; the run reported success.
• A(create_record dup, fault edge → recover) → try_catch { try: [B throws ECONNREFUSED] } — B bound as { code: 'DUPLICATE_RECORD', message: 'ECONNREFUSED…' } and swallowed.

The message and the code come from two different failures.

What is and is not being asked here

PR #14948 is taking the minimal identity guard (capture $error before the attempt; treat code as this attempt's only if the object identity changed) plus those two flows as pins. That closes the observable defect and is verified.

⛔ This card is not asking to re-litigate that. It records the underlying asymmetry, which the guard works around rather than removes, and which the next person to add a field to $error will meet in exactly the same way — with the same invisibility, because the failure mode is a plausible-looking wrong value rather than a crash.

Suggested direction (for triage, not a ruling)

The reviewer's alternative, recorded as the cleaner long-term shape: have the engine attach code to the Error it throws (around :7190) and have try_catch read it off the caught exception, so message and code are bound from the same failure by construction rather than by a freshness guard.

⚠️ That changes the engine's throw shape, which is a wider surface than a patch round should decide — which is why it was deliberately excluded from #14948 and filed here instead.

The more general question worth a decision: should the throw arm refresh $error unconditionally, matching the returned-failure arm? If there is a reason it is conditional on faultEdge, that reason is not recorded at the site and should be; if there is not, the asymmetry is the defect and the guard in #14948 becomes redundant.

Refs: PR #14948 / #14419 (where it was reproduced, and the guard that contains it) · the review's artefacts are named in its verdict comment on that PR

[os-zhuang]

分诊路由(本评论来自分诊座位)· R+150 · date -u 实测 2026-09-04T19:40:11Z

domain:services · finding · priority:p2。

落点与形状现验(同一次调用,origin/main fetch 后):packages/services/service-automation/src/engine.ts 上两条臂都在,且非对称仍然存在 ——

:7411  const faultEdge = isGuardRefusal(execErr)      ← throw 臂
:7414  if (faultEdge) {                                 ← 刷新被关在这个 if 里
:7507  const faultEdge = result.errorClass === 'guard'  ← returned-failure 臂
:7510  if (faultEdge) {

⚠️ 卡面写的 :7088 / :7167 已漂约 320 行 —— 符号在,行号不在,按符号定位(卡面自己也是这么说的)。落点 packages/services/* ⇒ 车道表 services。

p2 判据:观察类,且可观察的那一半已被 PR #14948 的最小身份守卫关掉并有 pin ⇒ 今天不是活缺陷,不是 p1。但也不是 p3:失效形态是「看起来合理的错值」而不是崩溃(实测两条流:message 与 code 来自两个不同的失败,而运行报告成功),⇒ 下一个往 $error 加字段的人会以同样的不可见方式再撞一次 —— 这正是 finding 存在的意义。

⚠️ 给认领方的边界(卡面已划,别越):卡里给的「更干净的长期形状」是让引擎把 code 挂到它抛出的 Error 上、try_catch 从捕获到的异常读 —— 那改的是引擎的 throw 形状,是比一轮补丁更宽的面,#14948 正是因此把它排除掉的。⇒ 若要走那条路,先上人工地板,⛔ 不在一次 finding 清理里顺手改抛出契约。

⭐ 卡里那个「更一般的问题」其实是本卡最省事的入口,值得先答:throw 臂为什么条件依赖 faultEdge? 若站点上没有记录理由 —— 现在确实没有 —— 那么要么补上那个理由,要么非对称本身就是缺陷,而 #14948 的守卫随之变成冗余。这个问题不需要改 throw 形状就能回答。

---

Generated by Claude Code

[os-zhuang]

分诊（半状态补齐）· pm:queue 补上 · priority:p2 / domain:services / finding 维持

⛔ 本席位只分诊：不认领、不派单、不写码、不合并、不裁决 decision-box 卡。本卡此前是半状态（有域、有级、有类型，⛔ 缺 pm:*）。

为什么是 pm:queue 而不是决策箱 —— 卡片里其实有两件事，只有一件需要裁

本卡结尾问「throw 臂是否应当无条件刷新 $error」，读起来像一个待裁问题。拆开看是两步：

1. 先查：if (faultEdge) 这个条件到底有没有理由？ 卡片自己给了判据 —— 「若有理由，那个理由没有写在现场，应当写上；若没有，那这个不对称本身就是缺陷。」 ⇒ 这一步是调查 + 记录，⛔ 不需要任何裁决，拿去就能做。
2. ⚠️ 只有复审建议的那条「更干净的长期形状」需要升级：让引擎在抛出时把 code 附到 Error 上（约 :7190），由 try_catch 从被捕获的异常上读 —— 那改变引擎的 throw 形状，是比一个补丁轮更宽的面（这正是它被 fix(automation): create_record surfaces the engine's DUPLICATE_RECORD code #14948 刻意排除、并落到本卡的原因）。

⇒ 打 pm:queue：第 1 步可派发。⛔ 若第 1 步的结论指向第 2 步的形状变更，请停下来拆卡送决策箱，⛔ 不要在一次「修不对称」里顺手改 throw 形状。

复核 —— 本席位只核了卡片所依赖的结构，⛔ 未重跑那两条流程

卡片给的行号是 PR #14948 head 上的（:7167 返回失败臂、:7088 throw 臂在 if (faultEdge) 内），⚠️ 本席位未在 main 上逐行确认这两处，因为它们随那条 PR 移动。接手者请在当前 head 上重取行号（本班次第 ⑩ 条纪律）。

本席位确认的是逻辑前提：区域内的节点没有自己的 fault edge（区域的合成子流程只带区域自己的边）—— 这一点与本班次 R+156 在 #15646 上复核过的 runRegion 行为一致（engine.ts:7870 把区域内的持久暂停转成错误，正因为区域是自成一体的合成流程）。⇒ 「区域内抛出 ⇒ 永远走不到 faultEdge 分支 ⇒ $error 不刷新」这条推理成立。

⭐ 这张卡最有价值的一句，请接手者原样带进 PR

message 与 code 来自两次不同的失败。

两条实测都长这样：{ code: 'DUPLICATE_RECORD', message: "Node 'mk' timed out after 20ms" } 被 catch 吞掉、运行报成功；{ code: 'DUPLICATE_RECORD', message: 'ECONNREFUSED…' } 同样被吞。⇒ 失败形态是一个「看起来很合理的错值」，不是崩溃 —— 这正是它此前不可见的原因，也是 priority:p2 的依据（本席位维持前一席位的定级）。

⛔ 三条边界

1. ⛔ 不要重新审 fix(automation): create_record surfaces the engine's DUPLICATE_RECORD code #14948。 那条 PR 取的是最小身份守卫（尝试前捕获 $error；仅当对象身份改变才认这次的 code）加两条流程做 pin，已验证、已关闭可观测缺陷。本卡记录的是它绕过而非消除的那个不对称。
2. ⭐ 为什么必须记录而不是就此打住（卡片的理由，本席位背书）：下一个往 $error 上加字段的人会以完全相同的方式撞上它，且同样不可见。 fix(automation): create_record surfaces the engine's DUPLICATE_RECORD code #14948 的 code 只是第一个对 $error 新鲜度有要求的消费者。
3. ⚠️ 相邻卡 service-automation: a PAUSING map inside a contained region leaves its progress state behind — later loop iterations skip items and the exhausted map returns success having run nothing #15646（PAUSING map 在 contained region 内留下进度残留，本席位 R+156 定级 p1 / pm:queue / domain:services）与本卡同文件、同「区域是合成子流程」这一根因家族，⛔ 但不是同一个缺陷。若同期开工请协调 engine.ts 上的改动。

Refs：PR #14948 / #14419（复现处与包含它的守卫）。

_{分诊席位 · claude-opus-5 · R+159 半状态巡查（objectstack）}

---

Generated by Claude Code