bluebird icon indicating copy to clipboard operation
bluebird copied to clipboard

Warning promise gives wrong file/line

Open Alex-Werner opened this issue 7 years ago • 7 comments

Using "bluebird": "^3.4.1", on node v6.3.1, I had a warning about promise not returned. That's okay, but the Warning tell me that :

(node:33144) Warning: a promise was created in a handler at domain.js:293:12 but was not returned from it, see http://goo.gl/rRqMUw
    at new Promise (D:\Projects\giraf-back\node_modules\bluebird\js\release\promise.js:77:14)` 

Which is not a file in my project (I assume it belong to node). If I now go in debuggability line 441 in release (or see here the file:line in the bluebird repo ), by removing the break, I can see the proper location

(node:34872) Warning: a promise was created in a handler at D:\Projects\giraf-back\databases\MongoDB\collection.js:77:12 but was not returned from it, see http://goo.gl/rRqMUw
    at new Promise (D:\Projects\giraf-back\node_modules\bluebird\js\release\promise.js:77:14)

(Edit: In fact, I can't, the proper location was the second items models\\request.js)

This is what I have by default (eg: not removing the break), if I display the stacktrace (by adding console.log(stack) between L440 and L441).

[ '    at Collection.insert (D:\\Projects\\giraf-back\\databases\\MongoDB\\collection.js:77:12)',
  '    at D:\\Projects\\giraf-back\\models\\request.js:10:30',
  '    at bound (domain.js:280:14)',
  '    at runBound (domain.js:293:12)',
  '    at runCallback (timers.js:570:20)',
  '    at tryOnImmediate (timers.js:550:5)',
  '    at processImmediate [as _immediateCallback] (timers.js:529:5)' ]
(node:36620) Warning: a promise was created in a handler at D:\Projects\giraf-back\databases\MongoDB\collection.js:77:12 but was not returned from it, see http://goo.gl/rRqMUw
    at new Promise (D:\Projects\giraf-back\node_modules\bluebird\js\release\promise.js:77:14)

Alex-Werner avatar Oct 13 '16 14:10 Alex-Werner

I'm getting the same from [email protected] on node 6.9.1

[ '    at addLinks (/usr/src/docca-pdf-server/node_modules/docca-pdf-document/lib/render/index.js:185:29)',
  '    at renderImage.then (/usr/src/docca-pdf-server/node_modules/docca-pdf-document/lib/render/index.js:204:7)',
  '    at bound (domain.js:280:14)',
  '    at runBound (domain.js:293:12)',
  '    at runCallback (timers.js:637:20)',
  '    at tryOnImmediate (timers.js:610:5)',
  '    at processImmediate [as _immediateCallback] (timers.js:582:5)' ]
(node:29) Warning: a promise was created in a handler at domain.js:293:12 but was not returned from it, see http://goo.gl/rRqMUw
    at Function.Promise.each (/usr/src/docca-pdf-server/node_modules/bluebird/js/release/each.js:24:12)

lecstor avatar Nov 15 '16 14:11 lecstor

getting the same issue as well

(node:15560) Warning: a promise was created in a handler at domain.js:293:12 but was not returned from it, see http://goo.gl/rRqMUw
at Function.Promise.attempt.Promise.try (/Users/blah/blah/node_modules/bluebird/js/release/method.js:29:9)

edit: note: sorry don't have a full stack trace :( its not an environment i have control over

vachi avatar Nov 22 '16 23:11 vachi

Shouldn't it be better that the package just display the full stacktrace ? Or to let us pass an option too short it or expand it at our wish ?

Alex-Werner avatar Nov 22 '16 23:11 Alex-Werner

I'm getting the same warning messages, and it's pretty much impossible to track down where my leaky promises are when I don't have LOC to track them down with. It's very difficult scouring through 184269 lines of JS!

danini-the-panini avatar Nov 29 '16 12:11 danini-the-panini

Seems like a bug, doesn't look like those lines should be removed by cleanStack

petkaantonov avatar Dec 06 '16 11:12 petkaantonov

@petkaantonov I've test it. This is what cleanStack(traceLines) returns me.

image

So i'm not sure it's a problem from cleanStack but instead going further I found that : image

In fact, I can fix it by removing traceLines[i - 1] and replacing it by traceLines[i]

image

I've tried to fix it doing so : image I added a conditionnal verification of traceLines[i] and keep the original lines (I'm not sure, but I think there is sometimes where this gaves the good answer ?) But it doesn't work see here : image

Alex-Werner avatar Jan 10 '17 14:01 Alex-Werner

Just ran into this problem. Such is life =/

AnyhowStep avatar Jun 27 '19 21:06 AnyhowStep