Error: performUpdateIfNecessary: Unexpected batch number ... in react v15.4.2 and react-dom v15.4.

[wking]

Spun off from #6895, which was closed with a request for reproducible test-cases to be filed as separate issues. The test-case I'd filed there (which failed on v15.4.1) is still failing on 15.4.2:

$ node --version
v6.9.4
$ npm --version
3.10.10
$ git clone git://github.com/wking/performUpdateIfNecessary-bug.git bug
$ cd bug
$ npm install
$ npm install
performUpdateIfNecessary-bug@0.1.0 /tmp/bug
├─┬ react@15.4.2
│ ├─┬ fbjs@0.8.9
│ │ ├── core-js@1.2.7
│ │ ├─┬ isomorphic-fetch@2.2.1
│ │ │ ├─┬ node-fetch@1.6.3
│ │ │ │ ├─┬ encoding@0.1.12
│ │ │ │ │ └── iconv-lite@0.4.15
│ │ │ │ └── is-stream@1.1.0
│ │ │ └── whatwg-fetch@2.0.2
│ │ ├─┬ promise@7.1.1
│ │ │ └── asap@2.0.5
│ │ ├── setimmediate@1.0.5
│ │ └── ua-parser-js@0.7.12
│ ├─┬ loose-envify@1.3.1
│ │ └── js-tokens@3.0.1
│ └── object-assign@4.1.1
├── react-dom@15.4.2
└─┬ react-scripts@0.7.0
  …
$ npm test
…a…
…
  console.error node_modules/fbjs/lib/warning.js:36
    Warning: performUpdateIfNecessary: Unexpected batch number (current 2, pending 1)

 FAIL  src/Bug.test.js
  ● does not duplicate requests for loaded nodes

    duplicate call for 7
      
      at Bug.<anonymous> (src/Bug.js:16:17)
      at ReactCompositeComponentWrapper._processPendingState (node_modules/react-dom/lib/ReactCompositeComponent.js:675:66)
      at ReactCompositeComponentWrapper.updateComponent (node_modules/react-dom/lib/ReactCompositeComponent.js:618:26)
      at ReactCompositeComponentWrapper.performUpdateIfNecessary (node_modules/react-dom/lib/ReactCompositeComponent.js:561:12)
      at Object.performUpdateIfNecessary (node_modules/react-dom/lib/ReactReconciler.js:157:22)
      at runBatchedUpdates (node_modules/react-dom/lib/ReactUpdates.js:150:21)
      at ReactReconcileTransaction.perform (node_modules/react-dom/lib/Transaction.js:140:20)
      at ReactUpdatesFlushTransaction.perform (node_modules/react-dom/lib/Transaction.js:140:20)
      at ReactUpdatesFlushTransaction.perform (node_modules/react-dom/lib/ReactUpdates.js:89:32)
      at Object.flushBatchedUpdates (node_modules/react-dom/lib/ReactUpdates.js:172:19)
      at ReactDefaultBatchingStrategyTransaction.closeAll (node_modules/react-dom/lib/Transaction.js:206:25)
      at ReactDefaultBatchingStrategyTransaction.perform (node_modules/react-dom/lib/Transaction.js:153:16)
      at Object.batchedUpdates (node_modules/react-dom/lib/ReactDefaultBatchingStrategy.js:62:26)
      at Object.batchedUpdates (node_modules/react-dom/lib/ReactUpdates.js:97:27)
      at Object._renderNewRootComponent (node_modules/react-dom/lib/ReactMount.js:320:18)
      at Object._renderSubtreeIntoContainer (node_modules/react-dom/lib/ReactMount.js:401:32)
      at Object.render (node_modules/react-dom/lib/ReactMount.js:422:23)
      at Object.<anonymous>.it (src/Bug.test.js:7:48)

  ✕ does not duplicate requests for loaded nodes (3ms)
…

There are no local catch calls in my code:

$ git grep catch
…no hits…

And really, there's not much code in the example at all :p. There may be bugs and catches deeper in the stack, but the only direct dependencies are react-scripts, react, and react-dom, so it seems like an issue in a Facebook-maintained repository (or possibly one of their dependencies, in which case a Facebook-maintained dependency may need to be bumped).

[gaearon]

In your example, [7, 7] is passed as slugs.
As a result, this code throws:

        if (calls[key]) {
          throw new Error('duplicate call for ' + key);
        }

Throwing inside setState callback breaks React, getting it into an inconsistent state, and producing further cryptic errors. I think this is consistent with what I said in #6895 (comment):

If you see a cryptic error like this it always means there is an earlier error from your component code that causes React to break. You need to scroll your console up and find the original error.

There is an error in your component code (you’re throwing it), and that’s what breaks React. React doesn’t support throwing errors in any user code (e.g. lifecycle methods, setState callbacks, etc). This breaks React. In current version, this causes cryptic errors. In future versions, we’ll fully unmount the tree as a result, but we will also provide a way to catch errors in components, in case you want to show a custom error message.

I hope this helps!

[wking]

On Tue, Feb 21, 2017 at 07:28:26PM -0800, Dan Abramov wrote: Throwing inside `setState` callback breaks React… … It’s just not supported to throw errors in any user code (e.g. lifecycle methods, `setState` callbacks, etc)…

It's probably worth documenting this in [1]. Grepping for ‘error’ and ‘throw’ there didn't turn up any hits.

… In future versions, we’ll fully unmount the tree as a result, but we will also provide a way to catch errors in components, in case you want to show a custom error message.

Having a way to catch and handle errors thrown by callbacks will be nice. Certainly nicer than writing callback code that never throws errors ;). [1]: https://facebook.github.io/react/docs/react-component.html

[gaearon]

It's probably worth documenting this in [1].

Feel free to send a PR 😉 .
Honestly I think it isn't worth the effort right now since we're changing this anyway in next release.

Grepping for ‘error’ and ‘throw’ there didn't turn up any hits.

While it's sad, the status quo for UI libraries is that uncaught errors can randomly break those libraries. This is not really unique to React. But we're fixing this.

[wking]

On Wed, Feb 22, 2017 at 09:51:48AM -0800, Dan Abramov wrote: >It's probably worth documenting this in [1]. Feel free to send a PR 😉 .

Filed as #9048.

Honestly I think it isn't worth the effort right now since we're changing this anyway in next release.

It didn't take long to write, and it will be easy to clobber with the docs for the new method ;).

[gaearon]

A small update on this. We just released React 16 beta which shouldn’t emit cryptic errors like this one. Even if the application code swallows an error, React 16 will still print it to the console. It might be too early for you to try React 16 (since ecosystem is still preparing for it), but this error should never occur in the future after you switch to it.

[adrifmonte]

In my case, I had some different providers, and their order were incorrect, hence those errors were raised.
If you're facing this warning, try reordering your nested providers in a kind of dependency concise order.