This alpha release alters the error-handling behavior of createAsyncThunk.
Changes
createAsyncThunk Error Handling
createAsyncThunk catches rejected promises from the promise payload callback, and dispatches a "rejected" action in response with the error value. That means that the thunk itself always returns a resolved promise.
We had a request to re-throw errors from the thunk, in case the calling code wants to chain off the promise or handle it further, so we've implemented that.
We've also removed the "finished" action that was previously being dispatched in a finally {} clause at the end, as it shouldn't truly be necessary - app logic should just need to respond to either the "fulfilled" or "rejected" actions.
When an error is caught in the thunk, we try to put it into the "rejected" action. But, since JS Error objects aren't actually serializable, we now check for Error objects and serialize them into plain JS objects with any of the relevant fields ( {name?, message?, stack?, code?}), or just the value itself if it's not an Error. Unfortunately, since the err value in a catch(err) {} clause doesn't have a type, the action.error field will come through as a type of any either way.
Finally, we've reordered the logic inside to avoid cases where an error while dispatching "success" gets swallowed and triggers the "AJAX failed" handling.