Esse envio que expirou salvou mesmo o seu trabalho?

O botão gira, o separador mostra um erro e o formulário que passou dez minutos a preencher desapareceu. O que não sabe é se a escrita chegou antes de a ligação morrer. Tratar essa incógnita como falha é como nascem comentários duplicados, encomendas duplas e pedidos de apoio repetidos.

Recupere por uma ordem fixa: guarde o texto, encontre o resultado e só depois decida se um segundo envio é permitido.

Comece pelo texto e pelo carimbo de data e hora

Copie o conteúdo da página antes de tocar em qualquer outra coisa, incluindo qualquer rascunho que o navegador ainda guarde no campo. Anote a hora, a página em que estava e a ação que fez, porque são esses três detalhes que tornam possível o resto da investigação. Se o separador ainda estiver aberto, deixe-o aberto até ler o registo de rede. Guardar o texto não custa nada e perdê-lo custa a tarefa inteira.

Depois separe as duas formas de falha que realmente pode observar. Uma ligação que caiu a meio do pedido e um servidor que respondeu com um erro parecem diferentes no painel de rede, e só a segunda diz algo sobre a decisão da aplicação.

Procure o resultado na vista da própria aplicação

Recarregue a vista de leitura que mostraria o resultado: a lista de comentários, o histórico de encomendas, a fila de pedidos ou o registo que estava a editar. Compare por conta, destino, hora e conteúdo em vez de pelo registo mais recente, porque outra pessoa pode ter escrito depois de si. Para uma tarefa em segundo plano, procure a referência existente e o respetivo estado em vez de criar uma nova operação como teste de conetividade.

Se o resultado estiver lá, terminou e o erro pertence ao caminho da resposta, não à escrita. Se não estiver, mantenha a possibilidade de a aplicação ainda não o ter confirmado: uma tarefa em fila, uma vista de leitura atrasada ou uma réplica atrasada podem esconder durante algum tempo uma escrita bem-sucedida.

Dê-lhe uma segunda olhada definida antes de tirar conclusões e anote a hora das duas verificações. Duas verificações separadas por vinte segundos são provas muito mais fracas do que duas separadas por dez minutos.

Decida se um segundo envio é seguro

A resposta depende da operação, não da sua paciência. O HTTP separa os métodos que podem ser repetidos com o mesmo efeito pretendido dos que não podem, e desaconselha tentativas automáticas do segundo tipo, salvo se se souber que a semântica o permite. Criar um comentário, fazer uma encomenda e enviar um pagamento costumam estar no segundo grupo, por isso um segundo clique que parece bem-sucedido nada diz sobre o primeiro.

Se mantém o cliente, use o mecanismo de nova tentativa ou de idempotência documentado pela API, e ligue-o à mesma operação lógica em vez de gerar uma chave nova para cada tentativa. Um identificador de pedido usado para rastreio não é uma chave de supressão de duplicados, a menos que o servidor o trate como tal.

curl -i -X POST https://api.example.net/v1/orders \
  -H "Idempotency-Key: 6f1c2a94-3b7e-4a10-9c22-5d0e8f7b1a63" \
  -H "Content-Type: application/json" \
  --data @order.json

A chave só ajuda se o serviço a guardar junto da operação e devolver o resultado original numa repetição. Teste esse comportamento num ponto final de pré-produção antes de confiar nele em produção.

Reúna provas antes de voltar a premir algo

Guarde o registo de rede em vez de uma captura de ecrã do erro. O método do pedido, o URL, a resposta ou o tempo limite e a hora em que aconteceu são o que um administrador consegue correlacionar com os registos da aplicação. Exporte ou copie o registo como comando só se depois retirar da cópia os cookies, os cabeçalhos de autorização e qualquer conteúdo privado. Deixe a sua própria sessão intacta e nunca reproduza um pedido capturado com credenciais como atalho.

Pergunte ao responsável do serviço uma pergunta concreta: a operação com este conteúdo a esta hora teve sucesso e existe uma referência? Essa pergunta tem resposta, enquanto "o site avariou" não tem.

O objetivo do exercício é estabelecer que a ação aconteceu exatamente uma vez. Uma mensagem de erro que pode fechar não é o mesmo que um registo em que pode confiar, e é o segundo que precisa antes de enviar qualquer outra coisa.