bug: retry.fetch ignores the caller's abort signal and retries aborted requests

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#5,116 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

  • #5127 par @umeraamir69 — fermée sans fusion

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
76/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
node.js, typescript
Domaine
backend, testing

Piste de recherche

Commencez dans packages/trigger-sdk/src/v3/retry.ts et lisez retryFetch avec les tests de nouvelle tentative existants. Reproduisez les trois cas d’annulation de l’issue : un init.signal annulé, le signal d’un Request annulé et un signal déjà annulé. Le travail est terminé lorsque chaque cas est rejeté avec AbortError sans envoyer de nouvelle tentative ; l’issue indique que les tests sont prêts, mais ne précise pas leur fichier.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Provide environment information

@trigger.dev/sdk 4.8.4 (main at 1fec779), Node 24.4.1, macOS.

Describe the bug

retry.fetch doesn't stop when the caller aborts, unlike fetch:

  1. Aborting init.signal mid-request is retried as a timeout. retryFetch can't tell the caller's AbortError from its own timeoutInMs, so it waits out the backoff and sends the request again, and the resend can't be aborted.
  2. The signal of a Request input is ignored. retryFetch only listens to init.signal.
  3. A signal that is already aborted still sends the request, because its abort event never fires.

All three are in retryFetch in packages/trigger-sdk/src/v3/retry.ts.

Reproduction repo

N/A

To reproduce

Inside a task, against an endpoint that takes about 500ms to respond:

const a = new AbortController();
setTimeout(() => a.abort(), 100);
await retry.fetch(url, { signal: a.signal }); // resolves 200 after resending

const b = new AbortController();
setTimeout(() => b.abort(), 100);
await retry.fetch(new Request(url, { signal: b.signal })); // resolves 200

await retry.fetch(url, { signal: AbortSignal.abort() }); // sends the request, resolves 200

fetch rejects with AbortError in all three cases.

Suggested fix

Use init.signal, falling back to the Request's signal, link it to every attempt (including when it is already aborted), and don't retry an abort that came from it. I have this ready with tests.

Additional information

Found while working on #2490.

Langage dominant
TypeScript
Étoiles
16.5k
Forks
1.5k
Merge moyen
1 j 15 h
PR mergées (30 j)
17

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de triggerdotdev/trigger.dev

Toutes les issues de triggerdotdev/trigger.dev

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.