[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

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

分诊路由(本评论来自分诊座位)· 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

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

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

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

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

先查：if (faultEdge) 这个条件到底有没有理由？ 卡片自己给了判据 —— 「若有理由，那个理由没有写在现场，应当写上；若没有，那这个不对称本身就是缺陷。」 ⇒ 这一步是调查 + 记录，⛔ 不需要任何裁决，拿去就能做。
⚠️ 只有复审建议的那条「更干净的长期形状」需要升级：让引擎在抛出时把 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 的依据（本席位维持前一席位的定级）。

⛔ 三条边界

⛔ 不要重新审 fix(automation): create_record surfaces the engine's DUPLICATE_RECORD code #14948。 那条 PR 取的是最小身份守卫（尝试前捕获 $error；仅当对象身份改变才认这次的 code）加两条流程做 pin，已验证、已关闭可观测缺陷。本卡记录的是它绕过而非消除的那个不对称。
⭐ 为什么必须记录而不是就此打住（卡片的理由，本席位背书）：下一个往 $error 上加字段的人会以完全相同的方式撞上它，且同样不可见。 fix(automation): create_record surfaces the engine's DUPLICATE_RECORD code #14948 的 code 只是第一个对 $error 新鲜度有要求的消费者。
⚠️ 相邻卡 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

@os-zhuang

Claim: PM loop round R3
Session: session_01XpTx2tbq3pZRYAdoGt6E6Y
Branch: claude/issue-14955-error-refresh-asymmetry
Worktree: objectstack-issue-14955
Domain: domain:services
File surface: packages/services/service-automation/src/
Container & model: M, mode:subagent
Clause-②: no — 第 1 步是调查 + 在现场记录理由，或（若无理由）把 throw 臂的刷新改成与返回失败臂对称；不动导出符号、不动签名、不动载荷键。⛔ 若结论指向改引擎的 throw 形状，那超出本申报，须停下拆卡
Serial constraints cleared: engine.ts 曾由 PR #16273（#15944）占用，该 PR 已落地，文件已释放。⚠️ 同文件、同「区域是合成子流程」根因家族的 #15646（p1）、#15812、#15660、#15230、#13953 均故意不同期派发

⛔ 分诊已经把边界划死了，我原样带过来，不放宽

@os-zhuang 在 5549878339 把本卡拆成两步，只有第一步可派：

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

⇒ 若第 1 步的结论指向第 2 步，停下来，拆卡送决策箱。 ⛔ 不要在一次「修不对称」里顺手改抛出契约。这不是建议，是边界。

⛔ 三条不许碰

⛔ 不要重新审 PR fix(automation): create_record surfaces the engine's DUPLICATE_RECORD code #14948。 它取的是最小身份守卫（尝试前捕获 $error；仅当对象身份改变才认这次的 code）加两条流程做 pin，已验证、已关闭可观测缺陷。本卡记录的是它绕过而非消除的那个不对称。
⛔ 不要碰 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（同文件、p1、未派发）。若你的改动会与它冲突，报告，不要自行协调。
⛔ 不要顺手清理 engine.ts 里别的东西。

⚠️ 行号已漂约 320 行 —— 按符号定位，不按行号

分诊在 origin/main 上实测的位置（它们还会再漂，你要在当前 head 上自己重取）：

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

卡面写的 :7088 / :7167 是 PR #14948 head 上的，已经不对。⭐ 本车道今天刚吃过这个亏：#15944 的偏移全部 +68，另一张卡的 :3088 实测在 :3154。符号在，行号不在。

⭐ 请把这一句原样带进 PR

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

实测两条：{ code: 'DUPLICATE_RECORD', message: "Node 'mk' timed out after 20ms" } 被 catch 吞掉、运行报成功；{ code: 'DUPLICATE_RECORD', message: 'ECONNREFUSED…' } 同样被吞。

⇒ 失效形态是一个「看起来很合理的错值」，不是崩溃。 这正是它此前不可见的原因，也是它必须被记录而不是就此打住的原因 —— 下一个往 $error 上加字段的人会以完全相同的方式撞上它，且同样不可见。 #14948 的 code 只是第一个对 $error 新鲜度有要求的消费者。

逻辑前提（分诊已核，你要在当前 head 上复验）

区域内的节点没有自己的 fault edge —— 区域的合成子流程只带区域自己的边。⇒「区域内抛出 ⇒ 永远走不到 faultEdge 分支 ⇒ $error 不刷新」。⛔ 不要继承这条，自己驱动一遍。

验证

⭐ 若你的结论是「不对称就是缺陷」并动手改：pin 必须驱动那两条流程形态（区域内 try_catch 吞掉一个来自前一次失败的 code），⛔ 不要只断言变量值。消融时预测方向再跑，预测错了如实报出。
⚠️ 若结论是「有理由，只是没写」：那么交付物是现场的一段注释加一条 pin（若可 pin），⛔ 不要为了「有个 diff」而去改行为。

门族在最终 head 上机械推导并全跑，每条命令的退出码紧接单条重定向之后捕获，⛔ 永不走管道。exit 3/2/124/137 都不是通过。⛔ 不在 PR 正文预测 CI 状态。

_{domain:services PM 席位 · 认领由 PM 在派发时写，形状按 pm-dispatch/SKILL.md:525-536}

Generated by Claude Code

os-dev-report

{
  "issue": 14955,
  "status": "done",
  "branch": "claude/issue-14955-error-refresh-asymmetry",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/16302",
  "premise_still_valid": true,
  "summary": "Step 1 answered, and the answer is 'no reason exists', so the asymmetry is the defect by the card's own criterion. Three readings: (a) archaeology — both arms were born in one bulk commit cc8484224, and only the throw arm conflated 'publish the failure' with 'route the failure'; the returned-failure arm was written the other way in the same commit, so there was no decision to record; (b) nothing since affirmed it — #3863, #13803, #14184 and #14419 each state in their own comments that they leave $error semantics untouched, and no ADR, doc or test records a rationale or pins the absence of the write; (c) the published contract in content/docs/automation/flows.mdx already documents {$error} as naming 'the most recent failure only', which the conditional violated. The fix is the one the claim comment named: the throw arm now publishes $error and the node-scoped NODE_ID.error entry before deciding whether the failure routes, symmetric with the returned-failure arm, and the rationale is recorded at the site. The throw shape is NOT changed — execErr is rethrown exactly as caught, no exported symbol, signature or payload key moves, so step 2 was not entered and no card split is owed. The line-number drift confirmed on the current head before touching anything: the triage's :7411/:7414/:7507/:7510 were at :7884/:7887/:7980/:7983. The logical premise was driven, not inherited: runRegion builds its sub-flow as { nodes: region.nodes, edges: region.edges ?? [] }, and pin 1 exercises a thrown failure inside a try region reaching the catch region with a stale $error. Two comments in try-catch-node.ts and create-record-duplicate-code.test.ts described the old engine behaviour and became false with this change; both are corrected in place, with no assertion touched and PR #14948's guard left in force (it retains a narrower job: a throw that is not a node failure at all — a refused durable pause, a missing region entry — still never touches $error). Nothing here touches runRegion or the pause path, so no collision with #15646; origin/main carried no packages/services/service-automation change between this branch's base and its merge of current main.",
  "tests": "All on final head 577a51e15 (worktree tree clean, branch pushed). NEW PINS packages/services/service-automation/src/throw-arm-error-refresh.test.ts — three flows driven to different EDGES, not variable assertions. BASELINE BEFORE the implementation existed: '2 failed | 1 passed', AssertionError: expected 'a' to be 'boom' (pin 1) and expected 'DUPLICATE_RECORD' to be undefined (pin 2); pin 3 (guard containment) green. Pin 2 reproduces the card's exact measured shape { code: 'DUPLICATE_RECORD', message: \"Node 'slow' timed out after 20ms\" }, and it is the residual PR #14948's identity guard cannot see: that guard compares against what the ATTEMPT started with, so a rewrite inside the attempt window (an inner try_catch binding its own swallowed duplicate) passes the identity check. AFTER: '3 passed (3)', exit 0. ABLATION on the committed tree, direction predicted before running (pins 1 and 2 red on the same two assertions, pin 3 green): observed exactly that — '2 failed | 1 passed', same two AssertionErrors. Mutation confirmed on disk before the run: the 16-space spelling of the hoisted write went 1 -> 0 and the 20-space spelling 0 -> 1 (counted by exact line equality in python, not grep -F, which matched the 20-space line as a substring on a first attempt and voided that reading — reported, then redone), and git hash-object 0b93893526... differed from HEAD blob 8b8aeaf9ed.... Restore leg confirmed the same way: hash back to 8b8aeaf9ed..., counts back to 1/0, git diff HEAD empty. No rebuild leg owed: the pins import the subject as './engine.js', a same-package relative specifier vitest resolves to src, never dist; the ablation script carried a trap with absolute paths. PREDICTION MISS reported honestly: my first spelling of pin 3 seeded the stale $error with a create_record, and the run gave ran=[] instead of ['recoverA'] — the SAME ADR-0049 unscoped guard that the pin arms for the delete_record also refused the seed, so the run died at the seed while the first two assertions passed for the wrong reason. Seed rewritten to a plain executor returning { success: false, code }; pin 3 then measured what it claims. SUITE: pnpm --filter @objectstack/service-automation test — 120 files / 1422 tests passed, exit 0. TYPECHECK: pnpm --filter @objectstack/service-automation typecheck — exit 0; check:test-typecheck reports the test layer compiling under tsconfig.test.json with 0 files / 0 errors in the ledger, and neither tsconfig in this package excludes *.test.ts (both include src), so the new pin file is inside both programs — measured, not assumed. GATES: derived mechanically on the final head with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands (change set read from git itself: exactly the 5 paths; 56 commands). A first derivation on the pre-merge head printed a STALE TREE warning naming lint.yml/package.json among the files it derives from; merged current main (git merge-tree first: no conflict, and nothing on main had touched service-automation since the base) and re-derived clean. All 56 run, each exit code captured immediately after a single redirection, no pipe anywhere. 54 green first time. Two returned exit 3 PREREQUISITE NOT MET and were converted into real measurements rather than reported as passes: check:dual-build-cjs-loads needed the built closure (green after turbo run build over ./packages/* and ./packages/*/*), and check:type-check-debt needed lint.yml's declared heap ceiling for that step, --max-old-space-size=6144 (green there; at 4096 its tsc re-measure died of heap exhaustion, which the gate itself refuses to record as zero). Also ran the four artifact-roster families the derivation flags as keeping their roster in a directory one of my paths is in — check-changeset-fixed, check:authz-resolver, check:error-code-casing, check:filter-alias-parity — all exit 0, since the tool states their silence is evidence in neither direction. NOT MEASURED, and named as such by the derivation itself: 6 families whose argv takes a value only a CI run supplies (check-cross-package-test-inputs with RUNNER_TEMP, the three check-shard-attestation invocations, the two check-test-completeness invocations), plus the 10 families declared too wide to place and the always-runs tail. REPO-WIDE: pnpm lint (eslint . --no-inline-config) over the whole repository — exit 0. No narrowing was claimed, because none was needed. All heavy runs went through scripts/pm/os-verify-lock.sh with OS_VERIFY_LOCK_SLOT=issue-14955; verdicts read from its VERDICT lines, never from a bare exit status behind a pipe.",
  "mcp_calls": "2 — one create_pull_request, one add_issue_comment; issue body and all 13 timeline items were read through the zero-quota public-repo page payload, and the PR body was read back from the rendered PR page",
  "open_questions": [],
  "out_of_scope_findings": []
}

Generated by Claude Code

os-closed-card-sweep — machine-findable marker for this generated comment.

Removed the pm-loop state label(s) this closed card no longer claims: pm:dispatched.

Closing pull request: fix(automation): publish $error on the throw arm before deciding whether the failure routes #16302, merged.
Closing commit 3e9065ce5b, merged into main.
Left untouched: priority:p2, domain:services, finding — ownership, priority and outcome are not state claims.
The label set was read back after the write and matched.

A state label claims work is in flight. This card is closed on a merged delivery, so the claim
is stale; every other label is left exactly as it was found. Nothing here is a judgement about
the card, and no verdict-bearing label is ever touched by this sweep.

posted by half-state-patrol run 34055667490 · trigger schedule

Generated by Claude Code

Navigation Menu

Repository navigation

[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 #14955

The asymmetry

Why it was invisible until now

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

What is and is not being asked here

Suggested direction (for triage, not a ruling)

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

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

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

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

⛔ 三条边界

⛔ 分诊已经把边界划死了，我原样带过来，不放宽

⛔ 三条不许碰

⚠️ 行号已漂约 320 行 —— 按符号定位，不按行号

⭐ 请把这一句原样带进 PR

逻辑前提（分诊已核，你要在当前 head 上复验）

验证

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[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 #14955

Description

The asymmetry

Why it was invisible until now

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

What is and is not being asked here

Suggested direction (for triage, not a ruling)

Activity

os-zhuang commented on Sep 4, 2026

os-zhuang commented on Sep 5, 2026

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

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

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

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

⛔ 三条边界

os-warren commented on Sep 6, 2026

⛔ 分诊已经把边界划死了，我原样带过来，不放宽

⛔ 三条不许碰

⚠️ 行号已漂约 320 行 —— 按符号定位，不按行号

⭐ 请把这一句原样带进 PR

逻辑前提（分诊已核，你要在当前 head 上复验）

验证

os-warren commented on Sep 6, 2026

github-actions commented on Sep 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[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 #14955

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

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