Fixes #4620

ADR-0119 D4 把 batchData 的 atomic 修成了真承诺。同一文件里的两个同胞当时不在那次 PR 的确认范围内,缺陷原样留着 —— 本 PR 只做 issue 的第 1、2 节。

修了什么

1. deleteManyData 的假原子(protocol.ts)

if (options?.atomic) break; 只是跳出循环:没有事务、没有回滚。失败前已删掉的行保持已删除,而响应以原子自居并把它们报成 success: true。这比 batchData 那次更糟 —— 部分删除没有自然的撤销手段,客户端无法从自己的请求里把行重建回来。

2. updateManyData 完全不读 atomic

选项被接受、在 BatchOptionsSchema 里被声明成「全有或全无」,却从未被读取。调用方要原子性,拿到的是 best-effort,且没有任何信号 —— 典型的 declared ≠ enforced,而且是写路径上的保证。

怎么修的:复用,不重新推导

D4 的三块料(原子臂、共享逐记录循环、fail-closed 能力闸门、ROLLED_BACK: / NOT_ATTEMPTED: 行标记)都已在 main 上,本 PR 一律复用。为避免出现第三、第四份事务处理代码(抄写正是下一个同胞漂移回谎言的路径),把 batchData 原子臂里除「逐记录循环 + 两个响应构造器」以外的部分抽成一个共享 runner runAtomicBatch,三个入口共用:

• atomic: true → 整批跑在一个 engine.transaction() 里,首个失败回滚此前全部写入;
• 回滚批次报告零成功:成功过的行标 ROLLED_BACK: record < i > failed — < cause >,没轮到的行标 NOT_ATTEMPTED: atomic batch aborted by record < i >,致因行保留自己的原始错误 —— 客户端能区分「已尝试但被撤销」与「从未执行」;
• atomic 优先于 continueOnError(后者的契约文本本来就把自己限定在 atomic=false);
• 无法回滚的运行时(无 engine.transaction(),或默认 driver 无 beginTransaction)→ 501 NOT_IMPLEMENTED,而不是静默降级成 best-effort。静默降级正是本 issue 的缺陷类别,所以这里 fail closed。

batchData 的行为一点没动,其既有测试文件未作任何修改仍全部通过。

行为变更(需要知会使用者)

atomic: true 的 deleteMany / updateMany 在不能回滚的运行时上从「静默 best-effort」变成 501 拒绝。想要 best-effort 就明确要 —— atomic: false 或不传。changeset 里写了这条。

非原子路径(含 continueOnError 交互与两个端点的响应形状)保持不变,并加了回归钉。

测试

新增 packages/metadata-protocol/src/protocol.many-data-atomic.test.ts(14 例,均引用 #4620)。假引擎是一个带快照/恢复事务语义的内存 store,所以回滚是真回滚:

• deleteMany 原子 + 中途失败:回滚后 a、c 两行仍可读(这是本 issue 的关键 —— 部分删除没有自然撤销),零成功,行标 ROLLED_BACK: / NOT_ATTEMPTED:;
• updateMany 原子 + 中途失败:先前的更新被恢复成旧值,同样零成功、同样标记;
• 两个端点在无事务能力的 engine / driver 上均 501,且一次写都没发生;
• 非原子路径逐条钉住:不开事务、保留此前成功、continueOnError 交互不变。

protocol.delete-many.test.ts 里原先钉住假原子的那一例(atomic aborts the remaining ids on the first failure,断言 succeeded: 1)改成钉拒绝语义 —— 它钉的正是本次要修掉的行为。

pnpm --filter @objectstack/metadata-protocol test
 Test Files  31 passed (31)
      Tests  260 passed (260)

npx vitest run src/protocol.many-data-atomic.test.ts
 Test Files  1 passed (1)
      Tests  14 passed (14)

pnpm turbo run build --filter=@objectstack/metadata-protocol   # tsup dts = tsc 类型检查,通过
packages/rest: rest-batch-size-cap + rest-delete-many-ingress   15 passed

刻意没做

issue 第 3 节(逐行结果形状 { id, success, error, record } 与 BatchOperationResultSchema 的 { errors, data } 分歧)未触碰。那是公开 wire 契约的方向决定,两个方向对已发布客户端的影响相反;ADR-0119 D4 当时刻意没让它搭在 bug fix 上,让它搭在这次修复上会是同一种静默兼容性破坏。已由单独的决策 issue 承接。

🤖 Generated with Claude Code

https://claude.ai/code/session_018iARDqtrhQgz6fVHDeDkbQ

Generated by Claude Code