caolan/highland

UnhandledPromiseRejectionWarning in node

SupernaviX opened this issue · 1 comments

Hi!

I've been introducing highland into a Node project at work, and I've noticed that I get warnings from node in certain conditions.

Specifically, when I run this snippet:

const oops = Promise.reject(new Error('muahaha'));
_(oops)
  .toNodeStream()
  .on('error', err => console.log('got it', err));

I see the following output:

(node:21215) UnhandledPromiseRejectionWarning: Error: muhahaha
    at fail (repl:1:31)
    at repl:1:3
    at Script.runInThisContext (vm.js:122:20)
    at REPLServer.defaultEval (repl.js:332:29)
    at bound (domain.js:402:14)
    at REPLServer.runBound [as eval] (domain.js:415:12)
    at REPLServer.onLine (repl.js:642:10)
    at REPLServer.emit (events.js:203:15)
    at REPLServer.EventEmitter.emit (domain.js:448:20)
    at REPLServer.Interface._onLine (readline.js:308:10)
(node:21215) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 21)
got it Error: muhahaha
    at fail (repl:1:31)
    at repl:1:3
    at Script.runInThisContext (vm.js:122:20)
    at REPLServer.defaultEval (repl.js:332:29)
    at bound (domain.js:402:14)
    at REPLServer.runBound [as eval] (domain.js:415:12)
    at REPLServer.onLine (repl.js:642:10)
    at REPLServer.emit (events.js:203:15)
    at REPLServer.EventEmitter.emit (domain.js:448:20)
    at REPLServer.Interface._onLine (readline.js:308:10)
(node:21215) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 21)

I think that this is happening because the promiseStream function is attaching the promise handlers inside of the new stream. Since the stream constructor is lazy when passed a function, the rejection handler is registered asynchronously; the rejection will be handled (assuming the stream is eventually consumed), but node still yells at me because it isn't handled right away.

Would it make sense to call promise.then synchronously when building the stream, to avoid this? I think if promiseStream constructed a new empty stream and used write when values were available, it could preserve its current behavior without triggering node warnings.

drgif commented

Just came here to say that I am encountering this problem, too (3.0.0-beta.10). It doesn't affect the correct functionality and I can live with the current implementation. If more people see this as a problem, I would be happy to have a look into the proposed solution (but I am far from being an expert).