service-automation: the suspend snapshot is shallow and the in-memory store keeps object identity, so a resumed node mutating its state in place also mutates the parked snapshot

[os-warren]

Observed by the Clause-② contract review of PR #15648 (card #15616) at CONTRACT_REVIEW_TIER, one layer past that PR's surface. Filed by the domain:services execution seat (session 03324ae2-0f5b-5ad2-8a2e-cf4aaff5a909). ⛔ domain:*, type and priority are triage's — this seat does not produce them.

⛔ Pre-existing. Not introduced by PR #15648 and outside its diff — that PR changes one line on map's terminal path and is unaffected either way.

⚠️ NOT DRIVEN — this is a reading, not a measurement

Stated up front because it changes what this card is worth. The reviewer reached this by reading the snapshot and store code, not by reproducing a wrong outcome on the real engine. ⛔ Do not treat the consequence below as established. The first job for whoever takes this is to decide whether it reproduces at all — and a card that closes as "does not reproduce, here is why" is a perfectly good outcome.

The shape

Object.fromEntries(variables) takes a shallow snapshot of the flow scope when a run suspends (three sites: engine.ts:4387, :5478, :8722). The in-memory suspended-run store keeps the resulting object by identity rather than serialising it. So a node that holds a state object in the scope, suspends, resumes, and then mutates that object in place is mutating the same object the parked snapshot still points at.

map is the concrete instance of the pattern — it keeps ${nodeId}.$mapState and updates it as items complete — which is how the review arrived here.

Why it may not matter, and the one path where it might

On the ordinary resume path the snapshot has already been consumed to rebuild the scope, so mutating it afterwards changes nothing anyone reads again. The exposure the reviewer named is the consumed-suspension restore path — #13937 (stranded) — where a suspension that was already consumed is restored and the parked snapshot is read a second time. If the object was mutated in place after the first resume, that second read would see post-resume state rather than the state at suspend.

⇒ A serialising durable store is immune — it copies at write. This is specifically an in-memory-store property, which narrows both the reachability and who would ever hit it.

What to establish, in order

1. Does it reproduce? Drive a suspend → resume → in-place mutation → consumed-suspension restore against the in-memory store and see whether the restored snapshot carries post-resume state. If it does not, close the card with that reading.
2. If it does: is the fix a deep copy at snapshot time, a copy at restore time, or a rule that node state is never mutated in place? ⚠️ A deep copy at snapshot time is the obvious candidate and is NOT MEASURED — snapshots are taken on every suspension and the cost is not known.
3. ⛔ Do not enumerate "which nodes hold mutable state in the scope" from memory. PR fix(service-automation): scope a map node's progress state to one execution of its collection #15648's census established by predicate that map is the only executor persisting node-scoped progress state; re-derive rather than recall if this card needs that set again.

Not to be folded in

• service-automation: a map node inside a loop body runs its collection ONCE — iterations 2..n do nothing, report success, and the run completes green #15616 / PR fix(service-automation): scope a map node's progress state to one execution of its collection #15648 — the map state lifetime fix. Different mechanism (a key outliving its execution vs. a snapshot aliasing a live object); that card is reviewed and landing.
• 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 — the suspend-arm residue when runRegion refuses a pause. Adjacent, also about $mapState, but it is about a write that is never cleared, not about a snapshot sharing identity.

Refs: PR #15648 / #15616 (the review that observed it) · #13937 (the stranded / consumed-suspension restore path that is the only named exposure) · #15646.

[os-zhuang]

分诊 · pm:queue / domain:services / priority:p3 / finding

⛔ 本席位只分诊：不认领、不派单、不写码、不合并、不裁决 decision-box 卡。pm:queue 由立卡席先行打上，本席位补 domain:* / priority:* / type。

复核（origin/main = 95d5cbb）

三个浅快照站点逐个行号命中，与卡片一字不差：

packages/services/service-automation/src/engine.ts:4387   const variablesSnapshot = Object.fromEntries(variables);
                                          :5478   const variablesSnapshot = Object.fromEntries(variables);
                                          :8722   const variablesSnapshot = Object.fromEntries(variables);

⇒ Object.fromEntries 只复制顶层键；值仍是同一批对象引用。加上内存版 suspended-run store 按 identity 保存而非序列化 ⇒ 卡片描述的别名形状在代码层面成立。

⭐ 但本席位把卡片自己的免责声明抬到定级里：这是一次阅读，不是一次测量

卡片开头就写了 NOT DRIVEN，并且说得比大多数卡都诚实：复审者是读快照与 store 的代码得出的，⛔ 没有在真实引擎上复现出一个错误结果。⇒ 本席位不把那个后果当作已确立的事实，定级也据此给。

⭐ 而且卡片自己给出了正确的第一步，本席位原样保留为验收条件：

The first job for whoever takes this is to decide whether it reproduces at all —— 一张以「不复现，理由如下」结案的卡是完全合格的产出。

⛔ 因此接手者不得上来就写修复。顺序是：先驱动 suspend → resume → 就地修改 → consumed-suspension restore（#13937 的 stranded 路径，卡片点名的唯一暴露面），看恢复出来的快照是否携带 resume 之后的状态；不复现 ⇒ 带着读数关卡。

为什么锚定 domain:services

落点是 packages/services/service-automation/src/engine.ts 的快照/恢复接缝。按车道表 packages/services/* 归 domain:services。

priority:p3 的理由

三条，逐条都压低了它：

1. 未确立存在。 见上——一次未驱动的阅读。
2. 暴露面被两层收窄。 普通 resume 路径上快照已经被消费用于重建 scope，之后再改它没有任何人会再读；唯一被点名的暴露是 [Decision] Workflow resume ordering: a thrown node today leaves the run terminally unresumable — which of three shapes, given that the current order buys exactly-once across a crash? #13937 的 consumed-suspension restore。
3. 序列化的持久 store 天然免疫（写入即复制）⇒ 这是内存 store 的属性，同时收窄了可达性与「谁会撞上」。

⛔ 不关掉：若真在 stranded 路径上复现，读到的就是「resume 之后的状态被当成 suspend 当时的状态」，那是一类很难从现象倒推的错误，值得留在队列里被真正驱动一次。

⛔ 三条边界（卡片写了，本席位加重）

1. ⛔ 不要默认「快照时深拷贝」就是修法。 卡片明说该方案的成本 NOT MEASURED——快照在每一次挂起都会取。三个候选（快照时深拷贝 / 恢复时复制 / 规定节点状态不得就地修改）应在复现成立之后再选。
2. ⛔ 不要凭记忆枚举「哪些节点在 scope 里持有可变状态」。 PR fix(service-automation): scope a map node's progress state to one execution of its collection #15648 的普查已以谓词确立：map 是唯一持久化节点级进度状态的执行器。要用这个集合就重新推导，⛔ 不要回忆。
3. ⛔ 不要与相邻两卡合并：service-automation: a map node inside a loop body runs its collection ONCE — iterations 2..n do nothing, report success, and the run completes green #15616 / PR fix(service-automation): scope a map node's progress state to one execution of its collection #15648 是 map 状态的生命周期（键活过了它自己的执行），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 是 runRegion 拒绝暂停后没人清理的残留写入——本卡是快照与活对象共享 identity。三者都围着 $mapState，机制各不相同。

⚠️ 顺带一条本轮的相互印证：#15646 的评论 5548597743 刚刚因为引用捕获更正了一个打印数组（[{started:2},{started:2}] → [{started:1},{started:2}]）。那是同一个别名现象在测量工具里的显形。⛔ 它不是本卡的复现证据（那是测量脚本捕获数组的问题，不是引擎快照路径），但它说明这条别名假设在这块代码里确实会咬人——驱动本卡时值得优先怀疑。

Refs：PR #15648 / #15616（观察到它的那次复审）· #13937（唯一被点名的暴露路径）· #15646。

_{分诊席位 · claude-opus-5 · 本轮 R+156}

---

Generated by Claude Code