Workflow SDK adds idempotent starts
Workflow SDK 5.4.0 atomically admits a run and claims its hook, preventing duplicate starts from racing through a separate lookup and start.
In **Workflow SDK 5.4.0**, `start()` can admit a run and claim a hook atomically. A duplicate token raises `HookConflictError` and identifies the run that owns it.
Use a domain identifier such as an order or request ID as the token to make starts idempotent. For duplicates, `resumeHook` can route the payload to the existing run; early payloads are buffered and delivered in order.
In **Workflow SDK 5.4.0**, `start()` can admit a run and claim a hook atomically. A duplicate token raises `HookConflictError` and identifies the run that owns it. Use a domain identifier such as an order or request ID as the token to make starts idempotent. For duplicates, `resumeHook` can route the payload to the existing run; early payloads are buffered and delivered in order. `experimental_minRetention` keeps a token unavailable after the run ends. The material does not specify when that option becomes stable.
This makes workflow start idempotency concrete: a domain token can atomically identify an existing run and hook, with duplicate payloads routed to that run and buffered in order. It narrows the general need for idempotency and recovery to a specific SDK mechanism; retention beyond run completion remains experimental.