calling `resetApiState` while a request is running will not re-initiate it since 1.9.0 changes

[samallisonds]

I have some async custom queries that were working in 1.8.6, but no longer work in 1.9.0.

The useQuery result is no longer being updated after the async operation completes. Simply reverting to 1.8.6 fixes it immediately.

I notice the tests for this area don't actually have anything to wait for. Perhaps a simple test with a Promise resolving after a short setTimeout might help. Sorry about the lack of real code, all I have is pretty involved. I suspect it is quite simple to reproduce? Hopefully the below helps....

const queryFnWithPromise = () => {
  return new Promise<{ data: string }>((resolve) => {
    setTimeout(async () => {
      resolve({data: 'foo'})
    }, 1)
  })
}

[phryneas]

redux-toolkit/packages/toolkit/src/query/tests/queryFn.test.tsx

Lines 62 to 66 in 4c32e29

	withAsyncQueryFn: build.query<string, string>({
	async queryFn(arg: string) {
	return { data: `resultFrom(${arg})` }
	},
	}),

This test actually does test for a queryFn that asynchronously resolves. It does so on next tick, but I just checked and it also works with a millisecond delay.

Could you please create a CodeSandbox that showcases this behaviour?

[samallisonds]

There must be some magic I'm missing going on there, I can't see what would introduce a delay. I'm in no way a javascript expert though!

I'll have a look now at creating a CodeSandbox, hopefully there's a working sample I can base it on somewhere.

[phryneas]

Every function that is async will return a Promise and every Promise will only ever resolve at the next tick, never synchronously.

[samallisonds]

Ah, thank you for the explanation. More like sleight of hand than magic!

I've made a basic thing in a codesandbox, but it didn't replicate the issue. So I've returned to my code...

What I've found is if I setup a basic Promise-> resolve setup like above, with a fixed return value, it returns and the component consuming the useQuery renders ok with that value. If I add an awaited fetch, it also renders that value as expected. However if add and await my MSAL/Microsoft Graph call, the component is rendered before the value is resolved - even though I'm still returning a fixed value etc.

All that the component has in it is the useQuery and some JSX to render the value, so I don't think it can be hiding anything.

This mysterious additional (and final) "update" of the useQuery has a status='pending', but is missing fields like requestId, startedTimestamp and even endpointName that were present during earlier renders.

Interestingly if I remove the await on the MSAL call, but still call it, the consuming component re-renders twice. First with a status of 'fulfilled' and my fixed value, then again shortly afterwards with a 'pending' status as above.

It is almost as if the MSAL stuff somehow resolves one of RTK Query's promises?? Which even I can tell sounds rather unlikely!

I know that's not a lot to go on, and probably is a terrible description, but I'm mentioning it now incase it rings any bells for you. I'll keep playing...

[phryneas]

That sounds like you immediately start a second query.
What do you see in the DevTools?
Also, what kind or argument are you passing into the query hook? Is it a plain object?

[samallisonds]

The MSAL code is from @microsoft/microsoft-graph-client by the way.

I don't pass any arguments to the query hook. The graph call is simply loading the currently authenticated user's photo. The bit that I "toggle" the await on is purely a MSAL bit of code too. There's no code of mine at all, let alone any other interactions with RTK. I wonder if MS uses RTK in their code?

What in particular should I look for in the DevTools?

[phryneas]

Please show me the code how you call the query hook in your component. It really helps a lot.
I suspect you are using status which you should probably never directly access (hence the deprecation mark on it).

As for stuff in the DevTools: just look at actions flying. Is a second request for the component actually started? Provide screenshots.

[samallisonds]

With various iterations of debugging

export const UserAvatar = () => {
  // const { data: userPhoto, isLoading, isFetching } = usePhotoQuery()
  // console.log('UserAvatar', {userPhoto, isLoading, isFetching})
  const response = usePhotoQuery()
  console.log('UserAvatar', response)
  const userPhoto = response.data

  if (!userPhoto) return null

  return (
    <AuthenticatedTemplate>
      <img src={userPhoto} alt="from user profile" />
    </AuthenticatedTemplate>
  )
}

[phryneas]

Ah, so you're not directly accessing status.

From looking at this:
Once this has data, there is no direct way it would ever make another request. The only thing I could think about would be your code manually initiating a query or something being invalidated somewhere.

Also, something inside a queryFn can never go back to fetching.

[samallisonds]

This is without the await on the MSAL call, as that is a bit more interesting.

export const msGraphApi = baseApi.injectEndpoints({
  endpoints: (builder) => ({
    photo: builder.query<string, void>({
      // queryFn: photoQuery,
      queryFn: async (arg, api, extraOptions, baseQuery) => {
        console.log('queryFn')
        return await new Promise<{ data: string }>((resolve) => {
          setTimeout(async () => {
            console.log('queryFn -> setTimeout')
            const response = await fetch('/')
            console.log('queryFn -> awaited fetch', { response })
            const response2 = await photoQuery()
            console.log('queryFn -> awaited photo', { response2 })
            // const response3 = await fetch('/')
            // console.log('queryFn -> awaited fetch', { response3 })
            const data = ''//'foo'
            resolve({ data })
          }, 5000)
        })
      },
    }),

[phryneas]

Have you looked into the Redux Devtools?

[samallisonds]

Redux Devtools

Ah! Those sound like they would be very useful in this situation! I'll investigate...

[samallisonds]

Thank you - I might be getting somewhere now! An MSAL event is triggering some of my code, which is then calling resetApiState. I guess it is the behaviour somewhere inside of that which is differing between 1.8.6 and 1.9.0.

I'll investigate this and see if it looks 'problematic' or, more likely, something I need to update in my code.

[samallisonds]

Thank you very much for your patient help. It looks like there was a small RTK Query change that sent a new pending status and empty data to my query hook after resetApiState was called. This didn't actually invalidate the query cache, so no corresponding update was triggered and the query hook remained in pending. Potentially there's some confusion as the query might have been in progress while this was triggered (?).

Anyway, I've re-arranged how my code works to avoid this by calling util.invalidateTags instead, and probably handling MSAL token refreshes a bit better along the way.

I'll leave you to consider whether the RTK Query behaviour is all good. I've confused myself way too much today to hazard a guess!