Workflow SDK 新增幂等启动
内容提要
Workflow SDK 的 start() 现在可以原子地接纳运行并认领 hook，重复启动会安全失败，取代了先检查再启动的竞态模式。token 作为幂等键，同一 token 只能由一个运行拥有；重复启动会抛出 HookConflictError 并携带冲突运行 ID，从而可将重复请求的负载转给已有运行。运行内的 createHook 绑定已认领的 hook，早期负载会按序缓冲。设置 experimental_minRetention 可在运行结束后仍拒绝迟到的重复请求。需升级至 workflow 5.3.1。
延伸解读
原子启动如何消除竞态
文章指出，旧的 getHookByToken() 再 start() 模式在查找与启动之间存在间隙，会导致重复启动竞态。新的 start() 将接纳运行与认领 hook 合并为一个原子步骤，重复启动会安全失败。这意味着开发者不再需要手动检查 hook 是否存在，SDK 在底层保证了同一 token 只能被一个运行拥有，从而简化了并发控制逻辑。
重复请求的负载路由策略
当重复启动抛出 HookConflictError 时，错误对象携带冲突运行的 ID。文章示例展示了捕获该错误后，使用 resumeHook 将重复请求的负载转发给已有运行。这样，重复请求不会创建新运行，而是把数据交给已拥有 token 的运行处理。运行内的 createHook 会绑定已认领的 hook，早期负载按序缓冲，确保数据不丢失且顺序正确。
token 作为幂等键的边界与保留
token 来自业务域（如订单 ID），仅凭 token 即可保证幂等性。文章说明，如果工作流内部从未调用 createHook，token 仅作为幂等键，运行正常完成。设置 experimental_minRetention 后，运行结束后 token 仍不可用，迟到的重复请求会被拒绝。这为需要长期防重复的场景提供了控制手段，但需注意该配置为实验性，且需升级至 workflow 5.3.1。
Q&A
Workflow SDK 的 start() 函数现在有什么新特性？
start() 现在可以原子地接纳运行并认领 hook，重复启动会安全失败，取代了之前先检查再启动的竞态模式。
如何避免工作流重复启动的竞态问题？
使用 start() 的原子启动，并传入 experimental_hook 选项指定 token 作为幂等键，重复启动会抛出 HookConflictError，从而避免竞态。
重复启动工作流时会发生什么？
重复启动会抛出 HookConflictError，并携带冲突运行的 ID（conflictingRunId），不会创建新的运行。
如何将重复请求的负载路由到已有的运行？
捕获 HookConflictError 后，使用 resumeHook(token, payload) 将负载发送给拥有该 token 的运行。
工作流内部的 createHook 如何与启动时认领的 hook 绑定？
在运行内使用 createHook({ token }) 并传入相同的 token，即可绑定到启动时已认领的 hook，不会注册新 hook，也不会产生冲突。
experimental_minRetention 有什么作用？
设置 experimental_minRetention 后，运行结束后 token 仍会保留一段时间（从 start() 算起），期间迟到的重复请求仍会被拒绝。
需要升级到哪个版本才能使用这些功能？
需要升级到 workflow 5.3.1 版本。
