Durable Task: retomar uma orquestração não autoriza repetir um efeito externo

O Microsoft .NET Blog apresenta cinco cenários de execução durável com Durable Task .NET SDK 1.26.0 e Durable Task Scheduler, de aprovação de faturas a agentes de incidentes.[9] Os trechos são exemplos de desenho, não uma aplicação completa compilada e testada.[9] O ponto mais importante é a fronteira entre lembrar o próximo passo e saber o que realmente aconteceu fora do workflow.

O que muda para quem desenvolve

No cenário de pagamentos, o artigo ressalta que um timeout não equivale a recusa: o provedor pode ter cobrado antes de a resposta desaparecer.[9] Para aprovações, o evento recebido é uma notificação, enquanto a decisão definitiva deve estar no banco da aplicação.[9] Em provisionamento, um timeout local não cancela uma criação já aceita pela nuvem.[9]

Minha interpretação é que durabilidade deve resolver continuidade sem fabricar certeza. O modelo de estados precisa representar “desconhecido” e “pendente”, além de sucesso e falha. Caso contrário, uma retomada pode transformar ausência de confirmação em autorização para repetir uma ação.

O texto também mostra que serializar contadores de uma entidade durável não serializa as gravações externas de um índice de busca.[9] Eu exigiria que o destino rejeitasse revisões obsoletas de forma atômica, em vez de confiar apenas na ordem de despacho do coordenador.

Como aplicar

Antes de escolher o runtime, desenhe uma tabela por efeito externo: sistema que guarda a verdade, identificador estável da operação, estados possíveis, consulta de confirmação e resposta quando a situação continua incerta. Inclua explicitamente quem pode autorizar uma nova tentativa.

Para um agente de incidentes, o artigo separa coleta, proposta, aprovação, execução e verificação; a aprovação deve autorizar aquela proposta específica, não um plano regenerado depois de um crash.[9] Minha proposta de implementação é persistir parâmetros e evidências do plano e conferir essa identidade novamente antes de acionar a ferramenta.

Faça um teste de recuperação em ambiente isolado. Interrompa o worker depois de salvar a proposta, durante a espera de aprovação e logo após uma ferramenta simulada registrar seu efeito, antes da confirmação ao workflow. Ao reiniciar, verifique se o sistema consulta a mesma operação em vez de executá-la novamente.

O resultado esperado não é somente “workflow concluído”. O aceite deve demonstrar que apenas o plano aprovado foi executado, que uma decisão vencida não foi reutilizada e que qualquer efeito incerto ficou pendente de reconciliação.

Cuidados e limites

O artigo alerta que compensação não é um desfazer automático: recursos compartilhados ou com dados de clientes não devem ser removidos por uma limpeza genérica de onboarding fracassado.[9] Quando a propriedade ou o estado forem incertos, eu escolheria interrupção e revisão, não exclusão por suposição.

Banco, fila e jobs convencionais continuam sendo opções adequadas quando já resolvem a continuidade de forma simples.[9] A decisão não deve premiar o runtime mais sofisticado. Deve reduzir a quantidade de situações em que o sistema precisa adivinhar o que aconteceu.

Fonte

[9] Fonte: Microsoft .NET Blog