Reduce generates 'unhandledRejection' events despite catch

1. What version of bluebird is the issue happening on? 3.5.1 & branch associated with #1489

2. What platform and version? (For example Node.js 0.12 or Google Chrome 32)

$node --version
v6.11.0

1. Did this issue happen with earlier version of bluebird? Does not reproduce in 3.5.0

Description of issue:

Reproduction here: https://github.com/erikerikson/chai-bluebird/tree/bb-1489-use-test

Executing:

const BbPromise = require('bluebird');

process.on('unhandledRejection', err => {
  console.log('###########################################################################');
  console.log(`UNHANDLED! ${err}`);
  console.log('###########################################################################');
});

BbPromise.reduce(
  [
    BbPromise.resolve('foo'),
    BbPromise.reject(new Error('reason')),
    BbPromise.resolve('bar')
  ],
  () => {},
  {}
)
  .catch(() => console.log('caught'))
  .then(() => console.log('after'))

Produces:

###########################################################################
UNHANDLED! Error: reason
###########################################################################
caught
after

Neither of the following produce this:

BbPromise.reduce(
  [
    BbPromise.resolve('foo'),
    BbPromise.resolve('bar')
  ],
  () => BbPromise.reject(new Error('reason')),
  {}
)
  .catch(() => console.log('caught'))
  .then(() => console.log('after'))

BbPromise.reduce(
  BbPromise.reject(new Error('reason')),
  () => {},
  {}
)
  .catch(() => console.log('caught'))
  .then(() => console.log('after'))

Perhaps related to #1468 #1487

[erikerikson]

If you consider: https://github.com/petkaantonov/bluebird/issues/1501#issuecomment-364270348

The rejection occurs immediately but the inspection of the rejected promise by reduce isn’t really scheduled until t+100ms.

In short the array and all of its promises, have been created and are the responsibility of code that is not reduce and it is asserting that reduce should pre-interact with all of them and then interact with them again in the expected process of executing the reduction function against each of them in serial.

The usual expectation with reduce is that a single iteration over the given iterable will occur. To catch rejections that occur prior to the reduction function being executed (and are thus placed on the event queue), a pre-iteration would be required. At least in theory, some iterations are stateful (consider a seek on a file moving a physical read head) and resetting is not a usual part of the contract. This ignores the performance impact and expectation mismatch.

So, I could see an argument that pre-inspection is appropriate to wipe up after users that aren’t thinking through their expectations like I hadn’t. On the other hand that would come at the cost of unnecessary instruction execution and potential side effects for users that had thought things through and appreciate the many interactions in these scenarios.

It isn’t that it couldn’t be considered a bug, it’s simply that fixing it could be considered introducing a bug.

[petkaantonov]

Pre iteration is fine if it only checks for bluebird promise and enables the unhandled rejection suppression flag on them. That has no side effects.