Como implementamos rollbacks baseados em saga no Cloudflare Workflows

O Cloudflare Workflows agora suporta rollbacks baseados no padrão saga de forma nativa, lançado após a atualização da versão 2 em maio de 2026. A implementação exige que o desenvolvedor passe um objeto de opções como terceiro argumento em step.do(), contendo uma função assíncrona em rollback, que recebe ctx, output (pode ser undefined se a etapa falhou antes de retornar) e error. Essa função é executada automaticamente em ordem inversa de início (não de conclusão) quando o workflow falha terminalmente, mesmo se a etapa falhosa tiver registrado um handler.

O rollback não é acionado por erros capturados localmente: só dispara se o workflow inteiro termina com falha. Os handlers são idempotentes por design, exigem uso de chaves de idempotência em sistemas externos (como provedores de pagamento) e suportam configurações próprias de retries (com limit, delay e backoff) e timeout. O status do rollback aparece como 'running' na API Workers e gera eventos específicos no painel de análise do Cloudflare.

Antes dessa atualização, equipes tinham de construir lógica de compensação manualmente, rastreando estados, orquestrando desfazimentos e lidando com falhas parciais fora do fluxo declarativo do workflow. Isso aumentava complexidade, risco de inconsistências e tempo de desenvolvimento. Agora, o padrão saga está integrado ao ciclo de vida nativo do Workflows, alinhando a ação primária e sua compensação no mesmo ponto de definição do código. Isso reduz a necessidade de estado externo para controle de rollback e melhora a confiabilidade em cenários críticos como transferências bancárias, reservas de estoque e provisionamento de infraestrutura distribuída.

Desenvolvedores em Node.js ou TypeScript usam o novo recurso com sintaxe clara: step.do('nome', async () => {...}, { rollback: async ({ ctx, output, error }) => {...} }). Não há mudança na semântica de execução: step.do() ainda inicia imediatamente a etapa, mantendo compatibilidade com pipelining de promises. A ordem de execução dos rollbacks é previsível, baseada em ordem de início, não de conclusão, o que evita surpresas em workflows paralelos. A exigência de idempotência não é opcional: é uma garantia necessária, pois o sistema pode reexecutar handlers em caso de falha durante o próprio rollback. A visibilidade via eventos e status na API permite monitoramento programático e integração com alertas.