What causes detached DOM references in a Node.js memory leak?

[ZoeyR]

I’ve been trying to track down a memory leak in my Node.js service for days, and the heap snapshots show this huge number of detached DOM tree references piling up, even though it’s a backend process. I’m genuinely confused about how that’s even possible without a browser environment. Has anyone else run into something like this where the profiling tools seem to report something that shouldn’t exist?

[LukeKJ]

I've run into this kind of thing in backend code too. Heap snapshots sometimes show detached DOM style objects even when there isn't a browser around. Libraries that build in memory trees ( jsdom, test helpers, or certain parsers) can keep references around, and V8 will keep them alive until nothing points at them. So the hint isn’t always a real browser leak; it often points to a lingering cache or closure.

[IsabellaIR]

I did a concrete pass: disabled the in memory DOM builder during profiling and forced GC, then compared snapshots. The heap grew for a bit and then leveled off after I cleared a cache that was holding onto a DOM like object. After removing that cache and stopping re-creating it, the growth stopped in later runs.

[Stella54]

Could this be profiler mislabeling rather than a real leak?

[Oliver_T]

I also chased down timers and long lived event listeners that closed over big objects. It didn’t end up being the DOM at all, but the profiler pointed there first. It’s easy to get misled, so I kept tracing references at GC time to see what was still reachable.