Utiliser fetch avec des délais d'expiration et AbortController

Objectif

Chaque appel fetch est borné dans le temps, peut être annulé quand son résultat n'est plus voulu, et signale les échecs HTTP comme des erreurs au lieu de traiter un 500 comme un succès.

Prérequis

Trois faits documentés. Une promesse fetch() n'est rejetée que lorsque la requête elle-même échoue (URL malformée, erreur réseau) ; elle n'est pas rejetée sur les statuts d'erreur HTTP, il faut donc vérifier response.ok ou response.status. Un AbortController fournit un signal ; appeler abort() rejette le fetch en attente avec une AbortError. AbortSignal.timeout(ms) renvoie un signal qui s'annule avec une TimeoutError après le temps actif donné, et AbortSignal.any([...]) combine plusieurs signaux.

Étapes

1. Écrire un seul assistant de requête utilisé partout. Il prend une URL, des options et un délai d'expiration, et construit le signal : AbortSignal.any([options.signal, AbortSignal.timeout(ms)].filter(Boolean)).
2. Une fois la promesse résolue, vérifier response.ok. En cas d'échec, lire une tranche bornée du corps à des fins de diagnostic et lever une erreur portant la méthode, l'URL et le statut.
3. Dans le catch, distinguer le type d'échec : err.name === "TimeoutError" (une nouvelle tentative peut être raisonnable), err.name === "AbortError" (l'appelant a annulé ; ce n'est pas un échec à signaler), une TypeError (problème réseau, DNS ou CORS ; à signaler), ou l'erreur HTTP de l'étape 2 (ne réessayer que les requêtes idempotentes avec des statuts susceptibles d'être réessayés).
4. Pour les requêtes qui se remplacent les unes les autres, comme la recherche au fil de la frappe ou les changements de route, garder un contrôleur par emplacement : annuler la requête précédente avant d'en démarrer une nouvelle et ignorer l'AbortError qui en résulte.
5. Garder le signal en vigueur pendant la lecture du corps (await response.json()), qui fait partie du même fetch ; ne pas démarrer de minuteur séparé pour cela.
6. Retirer les écouteurs ajoutés à des signaux de longue durée une fois terminé ; un signal de délai en attente avec des écouteurs reste actif jusqu'à ce qu'il se déclenche.
7. Tester les trois chemins avec un serveur factice : qui ne répond jamais (délai), qui répond 500 (erreur HTTP), annulé en cours de route (abandon).

Résultat attendu

Aucune requête ne peut rester bloquée indéfiniment, les requêtes annulées ne produisent aucun rapport d'erreur, et chaque échec HTTP remonte avec le statut et l'URL joints.

Limites et base de vérification

Le délai ne compte que le temps actif ; il se met en pause pendant qu'un worker est suspendu ou qu'une page se trouve dans le cache de navigation arrière-avant. Annuler ne défait pas une requête que le serveur a déjà traitée, les écritures ont donc toujours besoin de clés d'idempotence. Le comportement suit les pages MDN citées ; aucun chiffrage n'est revendiqué.

Réessayer après un délai d'expiration

Un délai d'expiration signifie généralement que le serveur est lent ou surchargé, si bien que les nouvelles tentatives ajoutent de la charge précisément là où cela fait le plus mal. Ne réessayer une requête arrivée en délai que lorsqu'elle est idempotente (GET, PUT, DELETE, ou un POST portant une clé d'idempotence), au plus une ou deux fois, avec un backoff aléatoire, et arrêter après des délais consécutifs plutôt que de continuer. Un serveur peut avoir terminé la requête avant que le client n'ait abandonné, si bien qu'une écriture réessayée sans clé d'idempotence peut s'exécuter deux fois. Traiter une TimeoutError sur une requête non idempotente comme un échec à signaler, pas comme une invitation à réessayer, et préférer le Retry-After propre au serveur lorsqu'un 429 ou 503 en fournit un.