Redux-saga: Using redux-saga with react-router-redux, actions fired in sequence from componentDidMount are not handled by the forked routine after navigating to a new page

[gajus]

Using redux-saga with react-router-redux, actions fired in sequence from componentDidMount are not handled by the forked routine after navigating to a new page.

The key components to replicate the issue are:

actions dispatched from BarView componentDidMount:

componentDidMount() {
  this.props.dispatch(START.create());
  this.props.dispatch(GET_RESERVATION_REQUEST.create());
}

and yield take(GET_RESERVATION_REQUEST.type); saga defined in BarView effects.js.

Here is a sandbox that you can use to replicate the issue:

https://codesandbox.io/s/rw9mwnyq0o

To replicate the issue:

1. Open https://rw9mwnyq0o.codesandbox.io/
2. Observe console.log output
3. Click "START" button

Result:

1. Route changes to "/bar".
2. "BAR_VIEW/START" action is intercepted by saga.

Expected result:

1. Route changes to "/bar".
2. "BAR_VIEW/START" action is intercepted by saga.
3. "GET_RESERVATION" action is intercepted by saga.

As a sanity check, try to simply load https://rw9mwnyq0o.codesandbox.io/bar and then reload the page. You will get both "BAR_VIEW/START" and "GET_RESERVATION" actions intercepted.

Sorry for a bloated example. I couldn't figure out how to replicate the same issue without using react-router, even though I doubt it is going to be responsible for the issue.

[Andarist]

I've managed to reduce it to the simpler case - https://codesandbox.io/s/qlj85r1479

[hapood]

I encountered same problems, yield "put" effect will cause giving over current saga excute flow.
In document effects are categorized as blocking or non-blocking, and "put" is non-blocking effect.
So all non-block effects should not give over current saga excute flow, is it right?

[Andarist]

Im working on releasing v1. Part of that is rewritten internal stdChannel, so it becomes a multicast. It solves this bug and some others. I've written failing test for the bug described in this issue and merged it into the mentioned stdChannel PR to confirm that. Therefore I'm closing this issue now, you can watch progress on v1 here. I don't have much time to work on this, so however slow the progress is it is steady at the moment, so I hope you won't have to wait too long for the release.