Initiate returns undefined when unwrapping after resetApiState

[Cambrionix-Matt]

I have places in my application where i call

const res = dispatch(api.endpoint.myEndpoint.initiate()).unwrap()

but when I call api.util.resetApiState() these return undefined, despite the type suggesting otherwise.

Either the initiate should reject, return the old response before the api is reset, or the types should be updated to match the behavior.

[markerikson]

@Cambrionix-Matt : what is the code sequence and timing of resetApiState() vs initiate()? Can you provide an example that repros this behavior?

[Matt-Ord]

I think resetApIState was triggered around the same time the initiate was fulfilled.

I won't be able to repo properly until next week but the general structure was

API 1 has an endpoint getData1

API 2 has an endpoint getData2 which calls api1.getData.initiate(). unwrap () inside the base query 2

There is a listener middleware which listens for Api1.getData1.matchFufilled and dispatched api2.resetAPIState (ie around the same time api2.getData2 is unwrapped)

[markerikson]

If api2.resetApiState() is dispatched while that second request is still in progress, then yeah, it doesn't surprise me that this broke. That's not intended usage, and it's likely that the resolution logic now has to deal with an empty state that has no cache entry, because you told RTKQ to remove them.

[Matt-Ord]

Yeah I'm not too surprised it went wrong - and the fix our end was just to not reset the API state as it was definitely not the right thing to be doing! I still think this is a bug if the types suggested it should never return undefined

[markerikson]

I'd disagree on that. The types are accurate for intended usage. adding | undefined here would force users to do additional checks that aren't necessary except in this specific broken scenario.

[Matt-Ord]

I think the ideal fix is to reject all initiate which are pending before the cache is removed. In the intended scenario for resetAPIState would you be able to guarantee that it wouldn't have any queries which happen to be resolved at the same time as calling reset, and what would happen if the initiate has not yet resolved?

[markerikson]

I just shipped a change in v2.9.2 to ensure that all outstanding requests get aborted when you dispatch resetApiState. Does that help this situation?