Tracking unfulfilled promises

[dominykas]

I've seen there's a lot of planning around debugging and promise graphs and all that, but they seem to focus around avoiding .end() and capturing exceptions. I guess what I'm proposing here is somewhat related to issue #65, yet, here it goes.

I'll admit, I haven't run into the issue just yet, however I am getting increasingly paranoid that at some point I'll leave a situation in my code where some deferreds would never reach a fulfilled state. Naturally, in something like an express app this would lead to dangling unfinished requests, timeouts and memory leaks.

What I'm looking for is some sort of monitoring tool to detect these conditions. My current approach is to record all promises that are created - this way I can see how many of them are still unresolved as time passes - if lots of them are "hanging" I'm at least aware that there is a problem somewhere in my app.

I've created a hack to achieve this: https://gist.github.com/3729142 however it'd be nice to have it incorporated into the library (I can probably submit a pull request if this is not an entirely bad idea). It should probably also have a setting to only do it conditionally. And another setting to capture stack trace to make it easier to find where the dangling ones are coming from...

Then again - have I missed something that already exists?

[domenic]

Just got a chance to look at your hack—it's very impressive. I don't think it would work as a by-default feature due to memory concerns, but I'm inspired to think about adding it to a debug mode (maybe a separate Q-debug package that includes your hack and others?). I'll have to let this roll around in my head for a few days…

[ForbesLindesay]

If we had a Q debug we could provide options to automatically end all promises that don't get used after a couple of seconds. We could also timeout promises automatically.

[dominykas]

We've been running this hack in production for over 6 months now, and only recently it occurred to me to check what effect it has on memory. In our case, the app is normally ~100-120Mb with the hack on, and ~70-90Mb with the hack off. We're creating ~250 promises/minute. IMHO it's not too bad and totally worth it :)

As a nice side effect, we're plotting a number of "slow promises" (>2s to fulfill) - this has helped us detect a failing hard drive (it took us a while to pinpoint, but the increase in "slow promises" was the first symptom) :)

[kriskowal]

See: #361