Usando fetch com timeouts e AbortController

Objetivo

Toda chamada a fetch tem um limite de tempo, pode ser cancelada quando o resultado deixa de ser necessário e trata falhas HTTP como erros, em vez de considerar um 500 como sucesso.

Pré-requisitos

Três fatos documentados. A promise de fetch() só é rejeitada quando a própria requisição falha (URL malformada, erro de rede); ela não é rejeitada em status de erro HTTP, por isso é preciso verificar response.ok ou response.status. Um AbortController fornece um signal; chamar abort() rejeita o fetch pendente com um AbortError. AbortSignal.timeout(ms) retorna um sinal que é abortado com um TimeoutError após o tempo ativo indicado, e AbortSignal.any([...]) combina vários sinais.

Passos

1. Escreva um único helper de requisição, usado em todo o código. Ele recebe URL, opções e um timeout, e monta o sinal: AbortSignal.any([options.signal, AbortSignal.timeout(ms)].filter(Boolean)).
2. Depois que a promise for resolvida, verifique response.ok. Em caso de falha, leia um trecho limitado do corpo para diagnóstico e lance um erro que traga método, URL e status.
3. No catch, ramifique conforme o tipo de falha: err.name === "TimeoutError" (uma nova tentativa pode ser razoável), err.name === "AbortError" (o chamador cancelou; não é uma falha a reportar), um TypeError (problema de rede, DNS ou CORS; reporte-o) ou o erro HTTP do passo 2 (repita apenas requisições idempotentes com status que admitem nova tentativa).
4. Para requisições que se substituem mutuamente, como busca enquanto se digita ou mudanças de rota, mantenha um controller por slot: aborte a requisição anterior antes de iniciar a seguinte e ignore o AbortError resultante.
5. Mantenha o sinal ativo durante a leitura do corpo (await response.json()), que faz parte do mesmo fetch; não inicie um timer separado para isso.
6. Remova os listeners que você adicionou a sinais de longa duração quando terminar; um sinal de timeout pendente com listeners é mantido vivo até disparar.
7. Teste os três caminhos com um servidor stub: que nunca responde (timeout), que responde 500 (erro HTTP) e cancelamento no meio da requisição (abort).

Resultado esperado

Nenhuma requisição pode ficar travada indefinidamente, requisições canceladas não geram relatórios de erro e toda falha HTTP aparece com status e URL anexados.

Limites e base de verificação

O timeout conta apenas o tempo ativo; ele fica em pausa enquanto um worker está suspenso ou uma página está no back-forward cache. Abortar não desfaz uma requisição que o servidor já processou, portanto escritas ainda precisam de chaves de idempotência. O comportamento segue as páginas citadas da MDN; nenhum tempo de execução é afirmado.

Nova tentativa após um timeout

Um timeout geralmente significa que o servidor está lento ou sobrecarregado, de modo que novas tentativas aumentam a carga justamente quando ela mais prejudica. Repita uma requisição que expirou apenas se ela for idempotente (GET, PUT, DELETE ou um POST com chave de idempotência), no máximo uma ou duas vezes, com backoff com jitter, e pare após timeouts consecutivos em vez de continuar. O servidor pode ter concluído a requisição antes de o cliente desistir, então uma escrita repetida sem chave de idempotência pode ser executada duas vezes. Trate um TimeoutError em uma requisição não idempotente como uma falha a reportar, não como um convite para tentar de novo, e prefira o Retry-After do próprio servidor quando um 429 ou 503 o fornecer.