Heeft die verlopen inzending je werk echt opgeslagen?

De knop draait, het tabblad toont een fout en het formulier dat je tien minuten hebt ingevuld is weg. Wat je niet weet, is of het schrijven is aangekomen voordat de verbinding wegviel. Die onbekende als mislukking behandelen is hoe dubbele reacties, dubbele bestellingen en herhaalde supporttickets ontstaan.

Herstel in een vaste volgorde: bewaar de tekst, zoek het resultaat en bepaal pas daarna of een tweede inzending is toegestaan.

Begin bij de tekst en de tijdstempel

Kopieer de inhoud van de pagina voordat je iets anders aanraakt, inclusief elk concept dat de browser nog in het veld houdt. Noteer de tijd, de pagina waarop je was en de actie die je deed, want juist die drie details maken de rest van het onderzoek mogelijk. Als het tabblad nog open is, laat het open totdat je het netwerkitem hebt gelezen. De tekst bewaren kost niets, en hem verliezen kost de hele taak.

Scheid daarna de twee soorten storing die je echt kunt waarnemen. Een verbinding die midden in het verzoek wegviel en een server die met een fout antwoordde zien er in het netwerkpaneel anders uit, en alleen de tweede zegt iets over de beslissing van de applicatie.

Zoek het resultaat in de eigen weergave van de app

Laad de leesweergave opnieuw die het resultaat zou tonen: de reactielijst, de bestelgeschiedenis, de ticketwachtrij of het record dat je bewerkte. Vergelijk op account, bestemming, tijd en inhoud in plaats van op de nieuwste vermelding, want iemand anders kan na jou hebben geschreven. Zoek bij een achtergrondtaak de bestaande referentie en de status ervan op in plaats van een nieuwe bewerking als verbindingstest aan te maken.

Als het resultaat er is, ben je klaar en hoort de fout bij het antwoordpad, niet bij het schrijven. Als het er niet is, houd dan de mogelijkheid open dat de applicatie het nog niet heeft vastgelegd: een taak in de wachtrij, een vertraagde leesweergave of een achterblijvende replica kunnen een geslaagd schrijven even verbergen.

Geef het een bepaalde tweede blik voordat je een conclusie trekt, en noteer de tijd van beide controles. Twee controles twintig seconden uit elkaar zijn veel zwakker bewijs dan twee controles tien minuten uit elkaar.

Bepaal of een tweede inzending veilig is

Het antwoord hangt van de bewerking af, niet van je geduld. HTTP scheidt methoden die met hetzelfde bedoelde effect herhaald kunnen worden van methoden waarbij dat niet kan, en raadt automatische herhalingen van de tweede soort af tenzij de semantiek het aantoonbaar toestaat. Een reactie plaatsen, een bestelling doen en een betaling versturen vallen meestal in de tweede groep, daarom zegt een tweede geslaagd lijkende klik niets over de eerste.

Als je de client onderhoudt, gebruik dan het retry- of idempotentiemechanisme dat de API documenteert, en koppel het aan dezelfde logische bewerking in plaats van voor elke poging een nieuwe sleutel te genereren. Een verzoekidentificatie voor tracing is geen sleutel om duplicaten te onderdrukken, tenzij de server die als zodanig behandelt.

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

De sleutel helpt alleen als de dienst hem bij de bewerking opslaat en bij een herhaling het oorspronkelijke resultaat teruggeeft. Test dat gedrag op een staging-endpoint voordat je er in productie op vertrouwt.

Verzamel bewijs voordat je weer iets indrukt

Bewaar het netwerkitem in plaats van een schermafbeelding van de fout. De verzoekmethode, de URL, het antwoord of de time-out en het tijdstip waarop het gebeurde zijn wat een beheerder kan correleren met de registraties van de applicatie. Exporteer of kopieer het item alleen als commando als je daarna de cookies, autorisatieheaders en alle privé-inhoud uit de kopie verwijdert. Laat je eigen sessie intact en speel nooit een onderschept verzoek met inloggegevens opnieuw af als snelkoppeling.

Stel de diensteigenaar één concrete vraag: is de bewerking met deze inhoud op dit tijdstip geslaagd, en bestaat er een referentie voor? Die vraag heeft een antwoord, terwijl "is de site kapotgegaan" dat niet heeft.

Het doel van de oefening is vaststellen dat de actie precies één keer heeft plaatsgevonden. Een foutmelding die je kunt wegklikken is niet hetzelfde als een registratie die je kunt vertrouwen, en het tweede heb je nodig voordat je iets anders verstuurt.