O que acontece quando um fluxo roda duas vezes ou falha no meio do caminho?

Uma nova tentativa precisa saber o que já aconteceu.

Um contato pode chegar duas vezes. Uma pessoa pode aprovar duas vezes. Uma conexão pode falhar depois que parte do fluxo já rodou. São situações diferentes: antes de repetir qualquer coisa, identifique o pedido, a ação pretendida e a evidência do resultado.

O exemplo mantém o registro e pede de novo.

Na demonstração no navegador, reinicie e rode Novo serviço. Marque Simular uma falha de conexão nesta aprovação e depois Aprovar resposta de demonstração. Confira a Conexão pausada e o histórico. Selecione Restaurar a conexão de exemplo, revise o texto de novo e aprove. O botão de restaurar desmarca a caixa de falha para que a próxima aprovação conclua o exemplo.

O que é mantido, e o que não pode se repetir?

Informações faltando continuam faltando depois da restauração. Se um contato incompleto for aprovado depois da recuperação, ele volta para Aguardando dados. Uma nova tentativa não inventa uma área, não confirma um agendamento nem recebe a resposta do cliente.

Uma falha parcial real é mais difícil.

Imagine que um fluxo conectado atualiza o registro de um serviço e depois perde a confirmação antes de registrar o sucesso localmente. O status local pode ficar incerto, mesmo que o destino tenha mudado. Repetir o fluxo inteiro poderia repetir um efeito externo.

Esse é um caso hipotético de produção; o exemplo da Fireflax não o simula. Uma implementação real precisa de identificadores permanentes para os pedidos e as ações pretendidas, de um registro mantido dos resultados, de verificações do destino e de uma regra para resultados incertos. A memória do navegador e um texto de mensagem igual, sozinhos, não bastam.

O kit inicial offline mantém um arquivo local e oferece um comando de pausa explícito, mas continua sendo um ensaio de um único processo. Ele não comprova novas tentativas simultâneas seguras, entrega exatamente uma vez, disponibilidade em produção nem reversão entre sistemas.

Use este checklist de recuperação.

1. Pause e preserve. Pare o fluxo envolvido pelo procedimento combinado. Guarde o pedido, as versões, o erro e as evidências do resultado.
2. Confira o destino. Verifique se a mensagem, o registro ou outra mudança pretendida aconteceu. Classifique como feito, não feito ou incerto.
3. Evite reenviar às cegas. Resolva a incerteza com a pessoa responsável e com as evidências do sistema. Confira os identificadores do pedido e da ação e a regra de duplicados.
4. Restaure com o responsável pelas permissões. Corrija ou autorize de novo a conexão real, se necessário. Restaurar o acesso não autoriza repetir todas as ações.
5. Revise de novo. Confira de novo o pedido mais recente e qualquer mudança na conversa, no rascunho ou na preferência de contato. Obtenha uma nova aprovação quando for exigida.
6. Confirme um resultado pretendido. Faça só a próxima ação autorizada, confira o resultado e registre o que aconteceu antes de voltar ao trabalho normal.

Defina o responsável e o substituto para estas etapas. Uma mensagem já enviada não deixa de ter sido enviada porque um registro interno foi reiniciado. Qualquer correção ou reversão precisa das suas próprias permissões e de limites confirmados.

Mantenha as evidências junto da passagem de bastão.

As execuções arquivadas do código-fonte e do kit inicial cobrem cinco casos definidos cada uma, incluindo aprovação repetida e aprovação com falha/recuperação. Elas registram entradas sintéticas, estados exatos e o histórico. A suíte separada de 21 testes do repositório também verifica a recuperação de informações faltando. Essas verificações finitas sustentam as descrições acima; não são uma garantia de entrega.