Cloudflare Remove Boilerplate de Saga dos Workflows de Agentes

A Cloudflare lançou rollbacks de saga para seu runtime Workflows em 25 de junho de 2026. O recurso permite que desenvolvedores anexem lógica de compensação diretamente a cada etapa, em vez de gerenciar um bloco catch crescente que rastreia o que foi concluído e o que precisa ser desfeito. O lançamento fecha uma lacuna que todo runtime de execução durável enfrenta: quando a etapa 4 de 6 falha, quais etapas devo reverter e em que ordem? A Cloudflare incorpora essa resposta dentro da definição da etapa.

A mecânica é um único objeto de opções em `step.do()`. Onde você anteriormente escrevia a operação forward e procurava por um bloco catch para encontrar o código undo correspondente, agora você escreve:

```js await step.do("debit-bank-a", () => bankA.debit(from, amount), { rollback: async ({ output }) => bankA.credit(from, amount, output.id), }); ```

A função rollback recebe `output` da etapa forward, mas deve lidar com `output === undefined`. Isso importa: um provedor de pagamento pode capturar uma cobrança antes de a etapa retornar um ID de confirmação, então a etapa falha sem o Workflows ver o `chargeId`. O rollback ainda executa — ele apenas recebe output indefinido e deve lidar com isso com segurança.

Duas regras governam quando o rollback é disparado. Primeiro, ele não é acionado em um erro capturado. Se o código do usuário captura uma exceção e o workflow continua, nenhum rollback é executado. O rollback começa apenas quando o workflow está prestes a falhar terminalmente. Segundo, etapas falhadas ainda são elegíveis para rollback. Uma etapa que interagiu parcialmente com um sistema externo antes de lançar registra seu handler de rollback no caminho de entrada; esse handler executará em falha terminal mesmo que o caminho forward nunca tenha sido concluído.

A ordem fica sutil com workflows paralelos. Etapas sequenciais fazem rollback em ordem reversa. Etapas paralelas são concluídas em ordem imprevisível, então o Workflows classifica por ordem de início de etapa reversa, não por ordem de conclusão reversa. Isso torna a sequência determinística independentemente de qual branch paralelo terminou primeiro — crítico quando dois passos paralelos escrevem em recursos compartilhados que devem ser desfeitos em uma sequência específica.

A Cloudflare está implementando o padrão saga: cada operação é emparelhada com uma transação compensatória que semanticamente a reverte em vez de desfazer uma escrita de banco de dados. Isso evita commit de duas fases entre sistemas externos — o débito do Banco A não pode ser revertido transacionalmente; deve ser compensado com um crédito. Sagas trocam isolamento atômico por disponibilidade e limites de sistemas independentes. O tradeoff é real: entre o débito sendo confirmado no Banco A e a compensação de crédito sendo executada, há uma janela de inconsistência. As aplicações devem tolerar essa janela ou projetar em torno dela.

Para engenheiros de plataformas ML, o padrão mapeia diretamente para workflows de agentes em múltiplas etapas. Um agente que chama ferramentas, cobra um cartão, atualiza um banco de dados e envia um job para uma fila de treinamento precisa de lógica de compensação se o push da fila falhar. Um pipeline de embedding que executa embed → store → index → notify precisa de semântica atômica entre quatro chamadas externas. Antes deste lançamento, gerenciar manualmente estado de rollback — quais etapas executaram, quais chaves de idempotência foram usadas, que ordem desafazer — era boilerplate que vivia fora das definições de etapa e desviava do caminho forward conforme o workflow evoluía.

Os handlers de rollback devem ser idempotentes. Devem ser seguros para tentar novamente, assim como as etapas forward. A documentação da Cloudflare é explícita: use chaves de idempotência do provedor de pagamento tanto na cobrança quanto no reembolso; torne as chamadas de liberação de inventário repetíveis. O modelo de execução durável do Workflows significa que um handler de rollback pode executar mais de uma vez se o runtime reiniciar no meio do rollback. Qualquer handler que não seja idempotente causará duplos reembolsos ou duplas liberações.

Se você estiver construindo orquestração de agentes ou pipelines de inferência em múltiplas etapas sobre um runtime de execução durável — Cloudflare Workflows, Temporal, Durable Objects ou equivalente — co-localizar lógica de compensação com cada etapa é o padrão que não apodrece. Compensação em bloco catch não dura.