Debugging a timeout leak

[jeremy-rifkin]

I think I have a timeout leak somewhere in my project:

Data from the node prometheus client which is looking at process.getActiveResourcesInfo().

I know of a lot of places where timeouts are created in my project but I can't find anything that could cause timeouts to build up like this, unless timeouts aren't cleared from the event loop when they expire. I can't rule out library code either.

Are there any tools I can use for figuring out where these timers are being created?

[eschablowski]

Realistically, the best way might be to override the setTimeout functions, similar to how JestJS and co. do it, and have a counter for each location they are being created.

A proof of concept would be (this would have to be tied into the Prometheus client):

const _setTimeout = setTimeout;

getStackTrace = function () {
  var obj = {};
  Error.captureStackTrace(obj, getStackTrace);
  return obj.stack
    .split("\n")
    .slice(1)
    .map((line) => line.trim());
};

const counter = PromClinet.Counter({
    name: 'metric_name',
    help: 'metric_help',

    labelNames: ['location'] as const,
  });

setTimeout = function (fn, delay) {
  const location = getStackTrace().slice(1, 3).join("\n");  // Get the last 2 lines, maybe needs to be bumped up if it lies inside some promise code
  counter.labels({ location }).inc();
  return _setTimeout(fn, delay);
};

I'm not going to tie this in myself, since this can backfire if Prometheus uses setTimeout (though that doesn't seem to be the case after a cursory glance