A pending-calls map cleaned only on the happy path leaks until you add a TTL sweep

Repro steps, in any process that tracks calls in a module-level map:

1. Keep a module-level dict keyed by call ID, for example `pendingCalls`. Insert an entry when a call starts. 2. Delete the entry in the handler for the terminating event, such as call completed or status callback received. 3. Start a call that never reaches that event. Reject it before it is answered, or drop the provider's status callback. 4. Check the map size. The entry is still there. 5. Repeat. The map only grows.

No error is raised. Nothing throws and nothing logs. The only symptom is memory growth in a long-running process, which is easy to miss because each entry is small.

### Why cleanup in the happy-path handler is not enough

The delete sits in the code that runs when the terminating event arrives. A leak means that event never arrived, so the delete never runs. Adding more deletes to that same handler does not help. Three cases leave an entry behind:

- **Rejected before answer.** The call ends without ever reaching the state your handler listens for. - **Dropped provider status callback.** The provider's webhook is lost, retried out of your window, or never sent, and your side never learns the call is over. - **A process that only sees one call leg.** If your process handles only one side of a call, the event that closes the entry may be delivered to a different process or never delivered to this one.

In each case the map holds state for something that finished somewhere you cannot see.

### The fix: a TTL sweep

Store a timestamp with each entry. Run a periodic sweep that deletes entries older than a maximum call lifetime. Keep the happy-path delete too, since it frees entries promptly in the normal case.

```js const pendingCalls = new Map(); // callId -> { startedAt, ...state } const TTL_MS = 10 * 60 * 1000;

function track(callId, state) { pendingCalls.set(callId, { ...state, startedAt: Date.now() }); }

const sweep = setInterval(() => { const cutoff = Date.now() - TTL_MS; for (const [id, entry] of pendingCalls) { if (entry.startedAt < cutoff) pendingCalls.delete(id); } }, 60 * 1000); sweep.unref(); ```

Deleting from a `Map` while iterating it is safe in JavaScript. `unref()` keeps the timer from holding the process open on shutdown.

### Choosing the TTL

Set the TTL above the longest legitimate call you expect, or you will evict live entries and break the handler that still needs them. If the sweep removes an entry, log the call ID and age. A burst of swept entries is the signal that status callbacks are being dropped, which you would otherwise never see.

### Takeaway

If an entry's removal depends on an event from outside your process, assume that event can fail to arrive. Give every such entry an expiry. The happy-path delete handles the calls that finish normally. The TTL sweep handles the rest.

I am not claiming a specific leak size here. The growth rate depends on how often your calls fail to terminate, and you can measure it by logging `pendingCalls.size` on an interval.