Hat dieser abgelaufene Submit Ihre Arbeit wirklich gespeichert?

Der Button dreht sich, der Tab zeigt einen Fehler, und das Formular, das Sie zehn Minuten lang ausgefüllt haben, ist weg. Was Sie nicht wissen: ob der Schreibvorgang noch vor dem Verbindungsabbruch ankam. Dieses Unbekannte als Fehlschlag zu behandeln, erzeugt doppelte Kommentare, doppelte Bestellungen und wiederholte Support-Tickets.

Stellen Sie in fester Reihenfolge wieder her: Text sichern, Ergebnis finden und erst dann entscheiden, ob ein zweites Absenden erlaubt ist.

Beginnen Sie mit dem Text und dem Zeitstempel

Kopieren Sie den Inhalt aus der Seite, bevor Sie irgendetwas anderes anfassen, auch jeden Entwurf, den der Browser noch im Feld hält. Notieren Sie die Uhrzeit, die Seite, auf der Sie waren, und die Aktion, die Sie ausgeführt haben, denn genau diese drei Angaben ermöglichen den Rest der Untersuchung. Ist der Tab noch offen, lassen Sie ihn offen, bis Sie den Netzwerkeintrag gelesen haben. Den Text zu sichern kostet nichts, ihn zu verlieren kostet die ganze Aufgabe.

Trennen Sie dann die beiden Fehlerformen, die Sie tatsächlich beobachten können. Eine Verbindung, die mitten in der Anfrage abbrach, und ein Server, der mit einem Fehler antwortete, sehen im Netzwerk-Panel unterschiedlich aus, und nur die zweite sagt etwas über die Entscheidung der Anwendung.

Suchen Sie das Ergebnis in der Ansicht der Anwendung selbst

Laden Sie die Leseansicht neu, die das Ergebnis zeigen würde: die Kommentarliste, den Bestellverlauf, die Ticket-Warteschlange oder den Datensatz, den Sie bearbeitet haben. Vergleichen Sie nach Konto, Ziel, Zeit und Inhalt statt nach dem neuesten Eintrag, denn jemand anderes könnte nach Ihnen geschrieben haben. Suchen Sie bei einem Hintergrundjob die vorhandene Referenz und ihren Status, statt einen neuen Vorgang als Konnektivitätstest anzulegen.

Ist das Ergebnis da, sind Sie fertig, und der Fehler gehört zum Antwortpfad, nicht zum Schreibvorgang. Ist es nicht da, halten Sie die Möglichkeit offen, dass die Anwendung es noch nicht festgeschrieben hat: ein eingereihter Job, eine verzögerte Leseansicht oder eine nachlaufende Replika können einen erfolgreichen Schreibvorgang eine Weile verbergen.

Geben Sie ihm einen definierten zweiten Blick, bevor Sie ein Fazit ziehen, und notieren Sie die Zeit beider Prüfungen. Zwei Prüfungen zwanzig Sekunden auseinander sind deutlich schwächere Belege als zwei Prüfungen zehn Minuten auseinander.

Entscheiden Sie, ob ein zweites Absenden sicher ist

Die Antwort hängt vom Vorgang ab, nicht von Ihrer Geduld. HTTP trennt Methoden, die mit derselben beabsichtigten Wirkung wiederholt werden können, von denen, bei denen das nicht geht, und rät von automatischen Wiederholungen der zweiten Art ab, sofern die Semantik es nicht bekanntermaßen erlaubt. Einen Kommentar erstellen, eine Bestellung aufgeben und eine Zahlung senden gehören meist zur zweiten Gruppe, weshalb ein zweiter scheinbar erfolgreicher Klick nichts über den ersten aussagt.

Wenn Sie den Client pflegen, nutzen Sie den Retry- oder Idempotenzmechanismus, den die API dokumentiert, und binden Sie ihn an denselben logischen Vorgang, statt für jeden Versuch einen neuen Schlüssel zu erzeugen. Eine Anfragekennung zum Nachverfolgen ist kein Duplikat-Unterdrückungsschlüssel, es sei denn, der Server behandelt sie als solchen.

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

Der Schlüssel hilft nur, wenn der Dienst ihn zum Vorgang speichert und bei einer Wiederholung das ursprüngliche Ergebnis zurückgibt. Prüfen Sie dieses Verhalten an einem Staging-Endpunkt, bevor Sie sich in der Produktion darauf verlassen.

Sichern Sie Beweise, bevor Sie erneut etwas drücken

Behalten Sie den Netzwerkeintrag statt eines Screenshots des Fehlers. Anfragemethode, URL, Antwort oder Timeout und der Zeitpunkt des Geschehens sind das, was ein Administrator mit Anwendungsdatensätzen abgleichen kann. Exportieren oder kopieren Sie den Eintrag nur dann als Befehl, wenn Sie anschließend Cookies, Authorization-Header und alle privaten Inhalte aus der Kopie entfernen. Lassen Sie Ihre eigene Sitzung unangetastet und spielen Sie niemals eine erfasste Anfrage mit Zugangsdaten als Abkürzung erneut ab.

Fragen Sie den Dienstverantwortlichen eine konkrete Frage: Ist der Vorgang mit diesem Inhalt zu dieser Zeit erfolgreich gewesen, und gibt es dafür eine Referenz? Diese Frage hat eine Antwort, "ist die Seite kaputt" hat keine.

Der Sinn der Übung ist festzustellen, dass die Aktion genau einmal passiert ist. Eine Fehlermeldung, die Sie wegklicken können, ist nicht dasselbe wie ein Datensatz, dem Sie trauen können, und den zweiten brauchen Sie, bevor Sie irgendetwas anderes absenden.