Usar fetch con tiempos de espera y AbortController

Objetivo

Cada llamada a fetch está acotada en el tiempo, puede cancelarse cuando su resultado ya no se necesita, y reporta los fallos HTTP como errores en lugar de tratar un 500 como éxito.

Requisitos previos

Tres hechos documentados. Una promesa de fetch() se rechaza solo cuando la propia solicitud falla (URL malformada, error de red); no se rechaza ante estados de error HTTP, por lo que debe comprobarse response.ok o response.status. Un AbortController proporciona una signal; llamar a abort() rechaza el fetch pendiente con un AbortError. AbortSignal.timeout(ms) devuelve una señal que se cancela con un TimeoutError tras el tiempo activo indicado, y AbortSignal.any([...]) combina varias señales.

Pasos

1. Escribir un único ayudante de solicitud usado en todas partes. Recibe la URL, las opciones y un tiempo de espera, y construye la señal: AbortSignal.any([options.signal, AbortSignal.timeout(ms)].filter(Boolean)).
2. Tras resolverse la promesa, comprobar response.ok. Ante un fallo, leer un fragmento acotado del cuerpo para diagnóstico y lanzar un error que lleve el método, la URL y el estado.
3. En el catch, distinguir según el tipo de fallo: err.name === "TimeoutError" (un reintento puede ser razonable), err.name === "AbortError" (quien llama canceló; no es un fallo que reportar), un TypeError (problema de red, DNS o CORS; reportarlo), o el error HTTP del paso 2 (reintentar solo solicitudes idempotentes con estados reintentables).
4. Para las solicitudes que se sustituyen unas a otras, como la búsqueda mientras se escribe o los cambios de ruta, mantener un controller por ranura: cancelar la solicitud anterior antes de iniciar la siguiente e ignorar el AbortError resultante.
5. Mantener la señal vigente mientras se lee el cuerpo (await response.json()), que forma parte del mismo fetch; no iniciar un temporizador aparte para ello.
6. Eliminar los listeners añadidos a señales de larga vida cuando ya no se necesiten; una señal de tiempo de espera pendiente con listeners se mantiene viva hasta que se dispara.
7. Probar los tres caminos con un servidor simulado: nunca responde (tiempo de espera), responde 500 (error HTTP), se cancela a mitad de vuelo (abort).

Resultado esperado

Ninguna solicitud puede quedarse colgada indefinidamente, las solicitudes canceladas no producen reportes de error, y todo fallo HTTP aflora con el estado y la URL adjuntos.

Límites y base de verificación

El tiempo de espera cuenta solo el tiempo activo; se pausa mientras un worker está suspendido o una página está en la caché de retroceso/avance. Cancelar no deshace una solicitud que el servidor ya ha procesado, por lo que las escrituras siguen necesitando claves de idempotencia. El comportamiento sigue las páginas de MDN citadas; no se afirma ninguna medición de tiempos.

Reintentar después de un tiempo de espera

Un tiempo de espera suele significar que el servidor está lento o sobrecargado, así que los reintentos añaden carga precisamente cuando más perjudica. Reintentar una solicitud que agotó el tiempo solo cuando es idempotente (GET, PUT, DELETE, o un POST con una clave de idempotencia), como máximo una o dos veces, con retroceso (backoff) aleatorizado, y detenerse tras tiempos de espera consecutivos en lugar de continuar. Un servidor puede haber completado la solicitud antes de que el cliente se rindiera, por lo que una escritura reintentada sin clave de idempotencia puede ejecutarse dos veces. Tratar un TimeoutError en una solicitud no idempotente como un fallo que reportar, no como una invitación a reintentar, y preferir el Retry-After del propio servidor cuando un 429 o 503 lo proporcione.