useQuery.networkStatus doesn't update status to (4). The refetch happens from mutation with refetchQueries

[CavidM]

here is mutation trigs refetching

const [removeFromCart, { data, loading, error }] = useMutation(MutationRemoveFromCart, {
    variables: { deviceId: parseInt(device as string) },
    refetchQueries: [{ query: QUERY_GET_DEVICE, variables: { id: device } }]
  })

here networkStatus is always 7

const { data, loading, networkStatus, error } = useQuery<DeviceGetType>(QUERY_GET_DEVICE, {
    variables: { id: device }
  });

Reproduction steps:
create any query. and send your first request.
on some another place run some mutation and pass refetchQueries to the query you just run.
you expect to see networkStatus is 4 during refetching but it is 7 and only after the query is done

[bignimbus]

Hi @CavidM 👋🏻 thanks for opening this issue! I'd be happy to take a look at this but I'm not certain how to help with the information given. We have a CodeSandbox template that you could fork to demonstrate the issue in a way that matches how your Apollo Client instance is configured. Any more detail you could provide would be helpful 🙏🏻

[CavidM]

Hi. Sure, please see my code under comment (javid's code).
Here is my changes: https://codesandbox.io/s/blissful-snowflake-7yg54l?file=/src/index.jsx:895-1017
notifyOnNetworkStatusChange: true added to ALL_PEOPLE query
refetchQueries: [{ query: ALL_PEOPLE }] added to ADD_PERSON mutation

[bignimbus]

Thanks so much @CavidM 🙏🏻 I was able to reproduce the issue as you described. Interestingly, when I change the refetchQueries array from [{ query: ALL_PEOPLE }] to ["AllPeople"], I'm able to get the networkStatus value to update to 4. See this fork. So I think that's the immediate workaround: if you're blocked on this, please use the query operation name in lieu of a reference to a query document. I'll share this with the team and we'll figure out next steps from there. Thanks again!

[bignimbus]

A few other findings I'm sharing for posterity:

1. This PR changed the docs to recommend the { query: MY_QUERY } syntax: Update mutations.mdx #9708
2. As demonstrated in this fork, you can also work around this issue by setting refetchQueries: [ALL_PEOPLE]

This code snippet was of interest:

apollo-client/src/core/QueryManager.ts

Lines 806 to 808 in 86ca77c

	} else if (isNonNullObject(desc) && desc.query) {
	legacyQueryOptions.add(desc);
	}

Based on the fact that an object with a query property is named legacy I'm strongly inclined to say that our docs should be updated. I'll get some clarity here and post another update when I can!

[bignimbus]

And one more finding:

#7813 introduced this legacyQueryOptions concept. This inline comment explains the intent further:

apollo-client/src/core/QueryManager.ts

Lines 845 to 847 in 86ca77c

	// We will be issuing a fresh network request for this query, so we
	// pre-allocate a new query ID here, using a special prefix to enable
	// cleaning up these temporary queries later, after fetching.

Given this context, it makes sense why you're seeing networkStatus go from 1 (loading) to 7 (ready) without stopping at 4 (refetch). So I'll double down on my above guidance and recommend filling your refetchQuery arrays with query document nodes or query operation names instead of the syntax that's in our docs.

[CavidM]

Thank you so much @bignimbus.
It works and the solution is more enough. I agree with you regarding the documentation.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
For general questions, we recommend using StackOverflow or our discord server.