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

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.