unhandledRejection Stack Traces are unhelpful #9523

machineghost · 2016-11-09T00:04:38Z

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?

The text was updated successfully, but these errors were encountered:

vitaly-t · 2016-11-09T00:14:25Z

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 · 2016-11-09T00:15:36Z

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 · 2016-11-09T00:18:59Z

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 · 2016-11-09T00:21:06Z

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

vkurchatkin · 2016-11-09T00:22:10Z

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

vitaly-t · 2016-11-09T00:22:31Z

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 · 2016-11-09T00:24:50Z

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

vitaly-t · 2016-11-09T00:25:31Z

@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 · 2016-11-09T00:27:22Z

@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 · 2016-11-09T00:29:29Z

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

addaleax · 2016-11-09T00:30:41Z

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

machineghost · 2016-11-09T00:30:47Z

Not sure why do you see a stack trace at all

I turned them on with --trace-warnings (the unhandled promise rejection warning was really bugging me ...)

try process.on('unhandledRejection', r => console.log(r));

Will do, and will report back.

EDIT
It worked, thank you! I got:

TypeError: Cannot read property 'bottom' of undefined
    at \*my code\*

That seems like a perfectly awesome way of tracing the origin of unhandled promise rejections ... if you're aware of it. I just feel bad for anyone who has the same problem as me, who doesn't have the luck to find this issue in a Google search.

vkurchatkin · 2016-11-09T00:31:14Z

Yeah, in that case it is expected, I think

addaleax · 2016-11-09T00:32:05Z

@vkurchatkin Expected but pretty much useless 😉 I’ll try to put together a patch for this and we’ll see whether it gains any traction.

Give better stack traces for `PromiseRejectionHandledWarning` and `UnhandledPromiseRejectionWarning`s. For `PromiseRejectionHandledWarning`, when it is likely that there is an `Error` object generated, it is created early to provide a proper stack trace. For `UnhandledPromiseRejectionWarning`, the stack trace of the underlying error object is used, if possible. Fixes: nodejs#9523

addaleax · 2016-11-09T01:25:04Z

PR @ #9525

Give better stack traces for `PromiseRejectionHandledWarning` and `UnhandledPromiseRejectionWarning`s. For `PromiseRejectionHandledWarning`, when it is likely that there is an `Error` object generated, it is created early to provide a proper stack trace. For `UnhandledPromiseRejectionWarning`, the stack trace of the underlying error object is used, if possible. Fixes: #9523 PR-URL: #9525 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Daniel Bevenius <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michaël Zasso <[email protected]>

Give better stack traces for `PromiseRejectionHandledWarning` and `UnhandledPromiseRejectionWarning`s. For `PromiseRejectionHandledWarning`, when it is likely that there is an `Error` object generated, it is created early to provide a proper stack trace. For `UnhandledPromiseRejectionWarning`, the stack trace of the underlying error object is used, if possible. Fixes: nodejs#9523 PR-URL: nodejs#9525 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Daniel Bevenius <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michaël Zasso <[email protected]>

Give better stack traces for `PromiseRejectionHandledWarning` and `UnhandledPromiseRejectionWarning`s. For `PromiseRejectionHandledWarning`, when it is likely that there is an `Error` object generated, it is created early to provide a proper stack trace. For `UnhandledPromiseRejectionWarning`, the stack trace of the underlying error object is used, if possible. Fixes: #9523 PR-URL: #9525 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Daniel Bevenius <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michaël Zasso <[email protected]>

d668 · 2017-09-19T20:30:17Z

hm, I have

process.on('unhandledRejection', err => {
    console.log("Caught unhandledRejection");
    console.log(err);
});

and the output I get is

Caught unhandledRejection
null

with node --trace-warnings app

any ideas?

Gaelan · 2017-10-09T22:57:20Z

Is there any reason process.on('unhandledRejection', r => console.log(r)) shouldn't be the default? It is a much more useful behavior, and there shouldn't be any harm from having it on.

endymion · 2017-10-20T01:28:42Z

I went through some pain for hours. Finally found this. And I agree: Why isn't that the default behavior? The default behavior is going to scare people away from using Promises.

nabilfreeman · 2017-10-25T13:55:02Z

For anybody else coming from Google or elsewhere, I am sorry for your arduous journey. Here lies your answer...

@vkurchatkin's code above was all I needed to fix this problem.

liesislukas · 2018-05-06T10:21:49Z

while catching unhandledRejection does work and provides backtrace:

ReferenceError: name is not defined
at handleInvoiceAdd (/Users/lukas/Desktop/www/trafikito.com/src/backend/api/routes/invoice/add.js:194:7)
at
at process._tickCallback (internal/process/next_tick.js:188:7)

I would not recommend to use it in production while unhandledRejection may cause the app to stay in broken state and should be restarted. So what I did, is I run it in non-production env + I still kill the app after logging the details.

  process.on('unhandledRejection', (r) => {
    console.error('#dfkfjks tracing unhandledRejection: ');
    console.error(r);
    process.kill(1);
  });

So i have the trace, app is still killed and restarted by pm2.

juanjose49 · 2018-11-06T14:45:47Z

For anybody else coming from Google or elsewhere, I am sorry for your arduous journey. Here lies your answer...

@vkurchatkin's code above was all I needed to fix this problem.

The real MVP ^^^

marcj · 2019-01-11T12:43:58Z

Not exiting the process when unhandledRejection is occured is very dangerous as it returns an exit code of 0, which means 'everything went fine'. Terrible for shell scripts, for CI, process manager, and the overall behaviour of your application.

Use instead:

process.on('unhandledRejection', error => {
    console.log(error);
    process.exit(1);
});

Don't use the code from @liesislukas either, as it does not kill your process, but the one with PID = 1, which is in Docker container your process, but in none-docker it will probably restart your whole operating system (https://unix.stackexchange.com/questions/7441/can-root-kill-init-process).

andrew-koster- · 2019-05-24T02:40:29Z

Why was this closed without being fixed (yes, there's a workaround)? Why is the PR to fix the same issue open since 2017? evanw/node-source-map-support#188

This fixes the issue of pods not restarting on database connection errors. It will also provide much better visibility into a variety of other unhandled promise rejections we get in Spoke. Ref: nodejs/node#9523 (comment)

machineghost closed this as completed Nov 9, 2016

addaleax added promises Issues and PRs related to ECMAScript promises. feature request Issues that request new features to be added to Node.js. labels Nov 9, 2016

addaleax reopened this Nov 9, 2016

addaleax mentioned this issue Nov 9, 2016

promise: better stack traces for --trace-warnings #9525

Closed

3 tasks

silverwind changed the title ~~unhandledRejection Stack Traces are Unhepful~~ unhandledRejection Stack Traces are unhelpful Nov 9, 2016

addaleax closed this as completed in 196d27d Dec 5, 2016

addaleax mentioned this issue Dec 21, 2016

v6.x backport: promise: better stack traces for --trace-warnings #10378

Closed

pragmaticivan mentioned this issue Mar 16, 2017

Trace warnings by default on dev mode LiferayCloud/magnet#68

Closed

reel mentioned this issue Aug 8, 2017

Unhandled promise usehenri/henri#24

Closed

1j01 mentioned this issue Oct 15, 2017

Promise rejection not handled with opn usage tapio/live-server#224

Open

benallfree mentioned this issue Oct 28, 2017

Unhandled promises exception handler adonisjs/core#688

Closed

thetutlage mentioned this issue Oct 29, 2017

Unhandled promises exception handler adonisjs/adonis-ignitor#1

Closed

Macil mentioned this issue Dec 8, 2017

Error handling and fromPromise() kefirjs/kefir#265

Open

evantahler mentioned this issue May 26, 2018

unhandled rejection in cluster mode actionhero/actionhero#1222

Closed

bchrobot mentioned this issue May 20, 2020

fix: log and exit on unhandled promise rejection politics-rewired/Spoke#670

Merged

7 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

unhandledRejection Stack Traces are unhelpful #9523

unhandledRejection Stack Traces are unhelpful #9523

machineghost commented Nov 9, 2016 •

edited

Loading

vitaly-t commented Nov 9, 2016 •

edited

Loading

machineghost commented Nov 9, 2016

addaleax commented Nov 9, 2016

machineghost commented Nov 9, 2016

vkurchatkin commented Nov 9, 2016

vitaly-t commented Nov 9, 2016 •

edited

Loading

vkurchatkin commented Nov 9, 2016 •

edited

Loading

vitaly-t commented Nov 9, 2016 •

edited

Loading

addaleax commented Nov 9, 2016

vkurchatkin commented Nov 9, 2016

addaleax commented Nov 9, 2016

machineghost commented Nov 9, 2016 •

edited

Loading

vkurchatkin commented Nov 9, 2016

addaleax commented Nov 9, 2016

addaleax commented Nov 9, 2016

d668 commented Sep 19, 2017

Gaelan commented Oct 9, 2017

endymion commented Oct 20, 2017

nabilfreeman commented Oct 25, 2017 •

edited

Loading

liesislukas commented May 6, 2018

juanjose49 commented Nov 6, 2018

marcj commented Jan 11, 2019

andrew-koster- commented May 24, 2019

unhandledRejection Stack Traces are unhelpful #9523

unhandledRejection Stack Traces are unhelpful #9523

Comments

machineghost commented Nov 9, 2016 • edited Loading

vitaly-t commented Nov 9, 2016 • edited Loading

machineghost commented Nov 9, 2016

addaleax commented Nov 9, 2016

machineghost commented Nov 9, 2016

vkurchatkin commented Nov 9, 2016

vitaly-t commented Nov 9, 2016 • edited Loading

vkurchatkin commented Nov 9, 2016 • edited Loading

vitaly-t commented Nov 9, 2016 • edited Loading

addaleax commented Nov 9, 2016

vkurchatkin commented Nov 9, 2016

addaleax commented Nov 9, 2016

machineghost commented Nov 9, 2016 • edited Loading

vkurchatkin commented Nov 9, 2016

addaleax commented Nov 9, 2016

addaleax commented Nov 9, 2016

d668 commented Sep 19, 2017

Gaelan commented Oct 9, 2017

endymion commented Oct 20, 2017

nabilfreeman commented Oct 25, 2017 • edited Loading

liesislukas commented May 6, 2018

juanjose49 commented Nov 6, 2018

marcj commented Jan 11, 2019

andrew-koster- commented May 24, 2019

machineghost commented Nov 9, 2016 •

edited

Loading

vitaly-t commented Nov 9, 2016 •

edited

Loading

vitaly-t commented Nov 9, 2016 •

edited

Loading

vkurchatkin commented Nov 9, 2016 •

edited

Loading

vitaly-t commented Nov 9, 2016 •

edited

Loading

machineghost commented Nov 9, 2016 •

edited

Loading

nabilfreeman commented Oct 25, 2017 •

edited

Loading