forceRefetch may lead to swallowed errors

[schadenn]

Hi there 👋

We realized yesterday that there may be an issue with forceRefetch (#2663). I'm not sure if the behaviour is intended:
When there is an error within the function passed as forceRefetch, it will trigger a rejected action with an error in it, which is swallowing that error being propagated to anywhere.
I created a reproduction here: https://codesandbox.io/s/rtkquery-forcerefetch-issue-6x4zl5
You can check the console to see the hook state which is stuck in pending (was stuck in uninitialized in our work repo). And the pokemonApi/executeQuery/rejected action which is dispatched on the store which includes the error.

It would've saved us some debugging time if that error would've appeared in the console (without implementing a custom middleware), so I'd like to know if I should create a PR to make this error be thrown - or if implementing a middleware to report these errors is the intended way?

[EskiMojo14]

hey there, thanks for the report! i've done some quick investigation on the RTK side of this, and found the chain of events that cause it.

1. the endpoint's forceRefetch is called during the createAsyncThunk's condition callback
2. in createAsyncThunk, throwing inside condition (which shouldn't happen usually, but obviously can if something's wrong with the code) means that no pending action is dispatched at all (but the thrown error is still caught and dispatched as a rejected action as usual)
3. RTKQ relies on this pending action to create the substate for each query, which is why if you log state from your middleware you can see that the queries state remains empty.
4. the handlers for rejected/fulfilled actions will only update state if they have a substate to update, which as mentioned above didn't get created.
5. because state was never updated, the hook remains hanging in pending state.

i can't think of an easy fix off the top of my head, but this isn't the first time in recent history we've talked about createAsyncThunk potentially swallowing undesired errors (#3795).