Workflow SDK ganha starts idempotentes com hooks atômicos no start()

O Workflow SDK mudou a forma de iniciar runs com deduplicação. Antes, o padrão era chamar getHookByToken() para ver se já existia dono do token e, só depois, chamar start(). Entre uma chamada e outra havia uma janela, e duas requisições simultâneas podiam passar na consulta e iniciar duas runs. A documentação já tratava isso como uma race condition de start duplicado.

Agora o start() admite a run e reivindica o hook num único passo atômico. O token vem do seu domínio (ID de pedido, de fatura, de importação ou de requisição) e é a chave de idempotência. Exatamente uma run é dona dele. Um start() duplicado lança HookConflictError com o conflictingRunId do dono e nunca vira run. O hook existe desde a admissão, então resumeHook funciona antes de a run executar, e payloads precoces ficam em buffer e são entregues em ordem. Dentro do workflow, createHook({ token }) com o mesmo token se vincula ao hook já reivindicado, sem registrar nada novo, sem adicionar step, e getConflict() resolve para null. Com experimental_minRetention, o token continua indisponível depois do fim da run, contado a partir do start(), e duplicatas tardias seguem recusadas. A atualização é para o workflow 5.3.1.

Para quem opera fluxos disparados por webhooks ou filas com reentrega, isso tira da aplicação o código de deduplicação manual e o risco de run duplicada, como cobrança ou importação repetida. Na leitura editorial, o ponto prático é tratar HookConflictError como caminho esperado e, se fizer sentido, rotear o payload duplicado para a run dona do token.