unhandledRejection Stack Traces are unhelpful

[machineghost]

Version: v6.9.1
Platform: Linux

If possible, please provide code that demonstrates the problem, keeping it as
simple and free of external dependencies as you are able.

If I could I would, but the whole problem is that I can't figure out where the problematic code is.

I have an unhandled promise rejection warning, and for obvious reasons I'd like to get rid of it. However when I try to figure out where it's coming from (by turning on stack traces for unhandled rejections) I get a trace like:

(node:31438) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): TypeError: Cannot read property 'bottom' of undefined
    at emitPendingUnhandledRejections (internal/process/promises.js:57:27)
    at runMicrotasksCallback (internal/process/next_tick.js:61:9)
    at _combinedTickCallback (internal/process/next_tick.js:67:7)
    at process._tickDomainCallback (internal/process/next_tick.js:122:9)

... which of course is completely unhelpful since it doesn't reference a single line of my code. But clearly my code caused the rejection, so is there any way that Node could point me to the source of the problem with the stack trace?

[vitaly-t]

Since promises are asynchronous, the only way to trace what occurred prior to next_tick is via a deep/long stack tracing, which is a feature supported by Bluebird, as one example, but not by Node.js.

[machineghost]

Man, and I was really trying to avoid using a 3rd-party promise library. Bummer.

But thanks for taking the time to provide clarification.

[addaleax]

I’ll take the liberty to reopen this because I think this would be really useful and I can’t see any reason why the .stack property the Error with which the promise was rejected would not be useful information here.

[machineghost]

Thanks @addaleax. I didn't think this was a feature that could/would be implemented, but I'm quite happy to be wrong!

[vkurchatkin]

@addaleax to be honest, seems like a bug to me. There is no reason to show such stack trace at all

[vitaly-t]

I can’t see any reason why the .stack property the Error with which the promise was rejected would not be useful information here.

For one thing, because it would be a very heavy feature, to be used with care. In fact, it is a real performance killer, if someone by mistake deploys to PROD with it, so, be careful adding it 😉

I'm taking about long promise loops, such as pseudo-recursion 😉

[vkurchatkin]

@vitaly-t you are talking about long stack traces, it's a different issue

[vitaly-t]

@vkurchatkin exactly. Why is it a different issue? What did I miss? 😄

You would need long stack tracing in order to capture the extra stack calls that's being discussed.

[addaleax]

@vitaly-t It’s just about displaying the stack trace that was created along with the error object itself, no deep or long traces or anything. :)

(idk if that’s the source of the confusion but the stack trace in the OP showed the stack at the time of the warning being emitted, not the Error object being generated)

[vkurchatkin]

@machineghost try process.on('unhandledRejection', r => console.log(r));. Not sure why do you see a stack trace at all

[addaleax]

I think that might come from --trace-warnings?