fetch mit Timeouts und AbortController einsetzen

Ziel

Jeder fetch-Aufruf ist zeitlich begrenzt, kann abgebrochen werden, wenn sein Ergebnis nicht mehr gebraucht wird, und meldet HTTP-Fehler als Fehler, statt einen 500er als Erfolg zu behandeln.

Voraussetzungen

Drei dokumentierte Tatsachen. Ein fetch()-Promise wird nur abgelehnt, wenn die Anfrage selbst fehlschlägt (fehlerhafte URL, Netzwerkfehler); es wird nicht bei HTTP-Fehlerstatus abgelehnt, weshalb response.ok oder response.status geprüft werden muss. Ein AbortController liefert ein signal; ein Aufruf von abort() lehnt das anstehende fetch mit einem AbortError ab. AbortSignal.timeout(ms) liefert ein Signal, das nach der angegebenen aktiven Zeit mit einem TimeoutError abbricht, und AbortSignal.any([...]) kombiniert mehrere Signale.

Schritte

1. Einen einzigen, überall verwendeten Request-Helfer schreiben. Er nimmt URL, Optionen und ein Timeout entgegen und baut das Signal: AbortSignal.any([options.signal, AbortSignal.timeout(ms)].filter(Boolean)).
2. Nach Erfüllung des Promise response.ok prüfen. Bei einem Fehlschlag einen begrenzten Ausschnitt des Bodys zu Diagnosezwecken lesen und einen Fehler auslösen, der Methode, URL und Status mitführt.
3. Im catch-Block nach Fehlerart verzweigen: err.name === "TimeoutError" (ein erneuter Versuch kann sinnvoll sein), err.name === "AbortError" (die aufrufende Stelle hat abgebrochen; kein zu meldender Fehlschlag), ein TypeError (Netzwerk-, DNS- oder CORS-Problem; melden), oder der HTTP-Fehler aus Schritt 2 (nur idempotente Anfragen mit wiederholbaren Status erneut versuchen).
4. Bei Anfragen, die einander ablösen, etwa Suche während der Eingabe oder Routenwechsel, pro Slot einen Controller behalten: die vorherige Anfrage abbrechen, bevor die nächste startet, und den resultierenden AbortError ignorieren.
5. Das Signal während des Lesens des Bodys (await response.json()) in Kraft lassen, da dies Teil desselben fetch ist; dafür keinen separaten Timer starten.
6. An langlebigen Signalen hinzugefügte Listener nach Gebrauch entfernen; ein anstehendes Timeout-Signal mit Listenern bleibt bis zu seinem Auslösen am Leben.
7. Die drei Pfade mit einem Stub-Server testen: antwortet nie (Timeout), antwortet 500 (HTTP-Fehler), wird mitten im Ablauf abgebrochen (Abort).

Erwartetes Ergebnis

Keine Anfrage kann unbegrenzt hängen bleiben, abgebrochene Anfragen erzeugen keine Fehlermeldungen, und jeder HTTP-Fehlschlag wird mit Status und URL sichtbar gemacht.

Grenzen und Prüfbasis

Das Timeout zählt nur aktive Zeit; es pausiert, während ein Worker angehalten ist oder eine Seite im Back-Forward-Cache liegt. Ein Abbruch macht eine vom Server bereits verarbeitete Anfrage nicht rückgängig, weshalb Schreibvorgänge weiterhin Idempotenzschlüssel brauchen. Das Verhalten folgt den zitierten MDN-Seiten; es werden keine Zeitangaben behauptet.

Nach einem Timeout erneut versuchen

Ein Timeout bedeutet meist, dass der Server langsam oder überlastet ist, weshalb erneute Versuche die Last genau dann erhöhen, wenn es am meisten schadet. Eine in ein Timeout gelaufene Anfrage nur dann wiederholen, wenn sie idempotent ist (GET, PUT, DELETE oder ein POST mit Idempotenzschlüssel), höchstens ein- oder zweimal, mit zufällig gestreutem Backoff, und nach aufeinanderfolgenden Timeouts abbrechen, statt weiterzumachen. Ein Server kann die Anfrage bereits abgeschlossen haben, bevor der Client aufgegeben hat, sodass ein wiederholter Schreibvorgang ohne Idempotenzschlüssel zweimal ausgeführt werden kann. Einen TimeoutError bei einer nicht idempotenten Anfrage als zu meldenden Fehlschlag behandeln, nicht als Einladung zum erneuten Versuch, und bei einem 429 oder 503 das serverseitige Retry-After bevorzugen, falls vorhanden.