fix: remove abort listener from user signal after fetch completes

[MaxwellCalkin]

Summary

• Fix memory leak in fetchWithTimeout(): When the user provides an AbortSignal, an abort event listener is added to forward abort events to the internal controller. However, this listener is never removed after the fetch completes. This causes a memory leak when users pass long-lived AbortSignal instances, as the listener retains a reference to the internal AbortController and prevents garbage collection.

Details

In src/client.ts, the fetchWithTimeout() method adds an event listener on line 806:

if (signal) signal.addEventListener('abort', abort, { once: true });

The existing code comments (lines 799-804) explicitly discuss the importance of avoiding memory leaks from closures by using _makeAbort() instead of arrow functions. However, while the timeout is correctly cleaned up in the finally block, the abort listener on the user's signal is never removed.

This means if a user passes a long-lived AbortSignal (e.g., from an AbortController that outlives individual requests), each request leaves behind a dangling listener that keeps the internal AbortController alive in memory.

The fix adds signal.removeEventListener('abort', abort) to the finally block, ensuring the listener is cleaned up regardless of whether the fetch succeeds, fails, or times out. Note that while { once: true } is used on the addEventListener call, this only removes the listener if it actually fires — it does not help when the request completes normally without the signal being aborted.

Test plan

• Verify existing tests pass
• The fix is a single line addition in a finally block, matching the pattern already used for clearTimeout(timeout)
• removeEventListener is safe to call even if the listener was already removed (no-op)

🤖 Generated with Claude Code