Cet envoi qui a expiré a-t-il vraiment enregistré votre travail ?

Le bouton tourne, l’onglet affiche une erreur et le formulaire que vous avez passé dix minutes à remplir a disparu. Ce que vous ignorez, c’est si l’écriture a abouti avant que la connexion ne meure. Traiter cette inconnue comme un échec, c’est ainsi que naissent les doublons de commentaires, les commandes en double et les tickets d’assistance répétés.

Récupérez dans un ordre fixe : gardez le texte, retrouvez le résultat, et seulement ensuite décidez si un second envoi est autorisé.

Commencez par le texte et l’horodatage

Copiez le contenu hors de la page avant de toucher à quoi que ce soit d’autre, y compris tout brouillon que le navigateur conserve encore dans le champ. Notez l’heure, la page où vous étiez et l’action que vous avez faite, car ces trois détails sont ce qui rend le reste de l’enquête possible. Si l’onglet est encore ouvert, laissez-le ouvert jusqu’à ce que vous ayez lu l’entrée réseau. Sauvegarder le texte ne coûte rien, le perdre coûte toute la tâche.

Séparez ensuite les deux formes de panne que vous pouvez réellement observer. Une connexion qui a lâché en cours de requête et un serveur qui a répondu par une erreur ne se ressemblent pas dans le panneau réseau, et seule la seconde vous dit quelque chose sur la décision de l’application.

Cherchez le résultat dans la vue propre à l’application

Rechargez la vue de lecture qui montrerait le résultat : la liste des commentaires, l’historique des commandes, la file des tickets ou l’enregistrement que vous modifiiez. Comparez par compte, destination, heure et contenu plutôt que par l’entrée la plus récente, car quelqu’un d’autre a pu écrire après vous. Pour une tâche en arrière-plan, cherchez la référence existante et son état au lieu de créer une nouvelle opération comme test de connectivité.

Si le résultat est là, vous avez terminé et l’erreur appartient au chemin de la réponse, pas à l’écriture. S’il n’y est pas, gardez la possibilité que l’application ne l’ait pas encore validé : une tâche en file, une vue de lecture retardée ou une réplique en retard peuvent masquer un instant une écriture réussie.

Donnez-lui un second regard défini avant de conclure, et notez l’heure des deux vérifications. Deux vérifications séparées de vingt secondes sont une preuve bien plus faible que deux vérifications séparées de dix minutes.

Décidez si un second envoi est sûr

La réponse dépend de l’opération, pas de votre patience. HTTP sépare les méthodes qui peuvent être répétées avec le même effet voulu de celles qui ne le peuvent pas, et déconseille les nouvelles tentatives automatiques du second type sauf si la sémantique est connue pour l’autoriser. Créer un commentaire, passer une commande et envoyer un paiement relèvent généralement du second groupe, raison pour laquelle un second clic qui semble réussi ne dit rien du premier.

Si vous maintenez le client, utilisez le mécanisme de nouvelle tentative ou d’idempotence documenté par l’API, et rattachez-le à la même opération logique au lieu de générer une nouvelle clé à chaque essai. Un identifiant de requête utilisé pour le traçage n’est pas une clé de suppression des doublons, sauf si le serveur le traite comme telle.

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

La clé n’aide que si le service la stocke avec l’opération et renvoie le résultat d’origine lors d’une répétition. Testez ce comportement sur un point de terminaison de préproduction avant de vous y fier en production.

Recueillez des preuves avant de presser quoi que ce soit

Conservez l’entrée réseau plutôt qu’une capture d’écran de l’erreur. La méthode de la requête, l’URL, la réponse ou le délai d’expiration et l’heure à laquelle cela s’est produit sont ce qu’un administrateur peut corréler avec les enregistrements de l’application. Exportez ou copiez l’entrée sous forme de commande seulement si vous retirez ensuite de la copie les cookies, les en-têtes d’autorisation et tout contenu privé. Laissez votre propre session intacte, et ne rejouez jamais une requête capturée porteuse d’identifiants comme raccourci.

Posez au propriétaire du service une question précise : l’opération avec ce contenu à cette heure a-t-elle réussi, et existe-t-il une référence ? Cette question a une réponse, alors que "le site a-t-il cassé" n’en a pas.

Le but de l’exercice est d’établir que l’action a eu lieu exactement une fois. Un message d’erreur que vous pouvez fermer n’est pas la même chose qu’un enregistrement auquel vous pouvez vous fier, et c’est le second dont vous avez besoin avant d’envoyer autre chose.