redux-observable: Reducer errors swallowed silently after epics' outputs

released discussed change as redux-observable@0.19.0

Technically we could remove the error catching entirely because the fix I did upstream in rxjs https://github.com/ReactiveX/rxjs/blob/stable/CHANGELOG.md#556-2017-12-21 fixed the actual swallowing issue, the console.error was just a workaround. The only issue with removing it is that anyone who has not yet updated their rxjs version high enough to pick up the fix will have swallowed errors again. But perhaps that’s indeed the correct solution, advising people to upgrade their rxjs instead.

Reopening. We merged a workaround where we logged all errors from reducers but I’m concerned about it or any other similar solution. See the discussion in #379.

@maxkostow whoops you’re right, I just fixed my example. Thanks! 😄

is it too late to recover from the error at this point? If you have one misbehaving epic, but the rest are totally fine, is it possible to not error the observable?

If you apply catch like combineEpics(...epics)(...args).catch(...) it’s too late–all your other epics have already been unsubscribed so while you could restart them (by returning the source observable which is the second argument) they would have lost any local state. Usually that’s not a big deal because the only state in your epics themselves should be transient state; like the state debounceTime maintains, etc. All else should be in the redux store.

If instead you want to protect each of them from terminating the others, you can call each epic individually and add catch on each resulting stream.

Here’s an example of that, but it may be hard to grok since it uses a lot of function composition:

const combineAndIsolateEpics = (...epics) => (...args) => {
  const isolatedEpics = epics.map(epic =>
    (...args) =>
      epic(...args)
        .catch((e, source) => {
          console.error(`${epic.name} terminated with error: ${e.message}, restarting it...`);
          return source;
        })
  );

  return combineEpics(...isolatedEpics)(...args);
};

const rootEpic = combineAndIsolateEpics(epic1, epic2);

Now if any individual epic errors out, we’ll log the error message and restart it, but the other epics will continue with no knowledge that it happened and maintain any state they had.

We’ve talked about whether this (or something else) should actually be how it works by default in #94, but haven’t reached a solid consensus yet. But we should at least document these patterns probably… 😞

There are potential issues with restarting epics after they error out, if the devs aren’t strictly aware of the implications. e.g. what if the redux store is in a different state than the epic expects? Does the epic emit anything at start up? What if the error happens infinitely so it’s erroring and restarting synchronously, locking up the browser? etc

EDIT: this particular situation no longer gets swallowed, but some other cases still do.

---

Minimum reproduction:

https://jsbin.com/dukixu/edit?html,js,output

const input$ = new Rx.Subject();

input$
  .mergeMap(() => Rx.Observable.of(1, 2))
  .subscribe(d => {
    throw new Error('some error');
  });

input$.next();

Also appears related to Subject usage (but could be a red herring)