Memory leak in discord.js MessageCollector when not stopped

Answer

In Discord.js v14 a MessageCollector keeps every message it receives in an internal Collection. That collection is only cleared when collector.stop() (or collector.dispose()) is called. The timeout option internally invokes stop() when it expires, so the end event is emitted and the cache is released automatically.

Confirmed behavior

• Calling collector.stop() deletes the internal message Collection and removes all listeners, making the message objects eligible for garbage collection.
• The built‑in timeout option triggers stop() automatically; collectors do not leak when a timeout is set.
• If a collector is never stopped, its internal Collection retains references to every collected message, causing process.memoryUsage().heapUsed to grow roughly linearly with the number of messages.

Practical verification steps

1. Start your bot with Node’s --expose-gc flag to enable manual garbage collection.
2. Measure the heap before creating a collector:

   const before = process.memoryUsage().heapUsed;
   

3. Create a collector (e.g., new MessageCollector(channel, {time: 5000})) and let it gather 100 messages.
4. After collection, call collector.stop() and measure the heap again:

   const afterStop = process.memoryUsage().heapUsed;
   console.log('heap after stop:', afterStop - before, 'bytes');
   

5. Repeat the same test but omit stop(). Measure the heap:

   const afterNoStop = process.memoryUsage().heapUsed;
   console.log('heap without stop:', afterNoStop - before, 'bytes');
   

6. Optionally trigger a GC with global.gc() and observe the heap drop after stop().
7. For a deeper check, run Node with --inspect and take heap snapshots before and after stop() using Chrome DevTools to confirm that no message objects are referenced.

What to check next

If heap usage remains high after calling stop(), verify that no custom listeners are attached to the collector or to individual messages, as those can keep references alive. If you suspect such listeners, share the relevant code snippet so we can confirm whether they are the source of the leak.