client.query does not obey requestPolicy "network-only"

[villesau]

urql version & exchanges:
"urql": "^2.0.6",
"@urql/exchange-graphcache": "^4.3.6"

Steps to reproduce

// inside react component:
const client = useClient();

const submit = async () => {
  const result = await client
    .query(
      GetRelatedData,
      { variable },
      { requestPolicy: "network-only" }
    )
    .toPromise(); 
    //...restof the submit
}

2. call submit multiple times
3. the query is executed only once

Expected behavior
Since the query has { requestPolicy: "network-only" }, it should always fetch the results

Actual behavior
the query is executed only once

In my case I'm fetching upload urls for each uploadable file, and each call returns a new url for upload. Each url can only be used once, so every upload requires an unique result that the server generates.

[kitten]

Hiya ✌️

That's expected behaviour. To a certain extent, even without a cache it's expected that queries behave consistently and predictably — in other words, are side-effect free. It's likely a better idea to model your generation of upload URLs as a mutation instead if you're semi-randomly (at least as it looks from the outside) returning differing values.
Otherwise urql may always assume, at least via the dedupExchange that the same query is repeatable. Even the Client itself groups queries in the interest of avoiding work and registering whether a query is currently "active" or not by its key

As per the spec; https://spec.graphql.org/October2021/#sec-Mutation

It is expected that the top level fields in a mutation operation perform side-effects on the underlying data system.

In reverse, hence some assumptions are made in urql about queries; specifically each operation gets a key that's assigned based on its document and variables.

https://formidable.com/open-source/urql/docs/architecture/#how-operations-get-to-exchanges

So, you have two options:

• You can force urql to make different calls by ensuring that your operation's key changes, e.g. by passing some changing variables to the query
• You can instead use a mutation for which no consistent results are expected, since they're by definition side-effects

So, while I'd recommend the second approach, it's also possible to use the first.

As per what "request policies" mean; They only really alter what the cache does, however, they don't stop the dedupExchange from deduplicating the operation, and they don't stop the Client from treating one result to your operation as different from another, if they share the same key

[villesau]

Hi, and thanks for the quick and thorough answer! I think it could make sense to document the behaviour next to request policies since at first it very much looks like a bug.

[villesau]

@kitten Ok I now made the changes, but see something very weird: The requests are now fired, and the network request returns an unique value for each request. However! the above query (changed to mutation) returns the latest resolved result for all of the mutations. So while the network request returns unique values, I'm seeing only the latest values if they fire right after each others (in a loop for example).

Something like this:

// inside react component:
const client = useClient();

const submit = async () => {
const results = await Promise.all(files.map(file =>   await client
    .mutation(
      GetRelatedData,
      { variable },
      { requestPolicy: "network-only" }
    )
    .toPromise() ))
console.log(results) // <- the latest resolved value multiple times
    //...restof the submit
}

[kitten]

Sorry! After rereading my response it seems I mistyped one important detail. The operation keys also apply to mutations; so, it very much depends on whether you treat them as fire-and-forget (where it doesn't matter) or use the results. urql will still conflate both results when the result is identical. We actually actively avoid this when a File object is passed to the variables, by generating a unique ID for it, so that the operation key changes

This obviously doesn't apply automatically in this case and you may still need to assign a random ID to the mutation. I'm actually thinking that that's a limitation we should definitely lift.
You're 100% right in saying that it's unexpected, when it comes to mutations. They're always unique calls and since they'll only have one result we should likely use reference equality to compare mutation operations rather than their keys

[thojanssens]

Hello, I'm new to urql. I don't understand when you write

it's expected that queries behave consistently and predictably — in other words, are side-effect free

Do you mean that a query (with same variables) is expected to return the same result from the server? But the data may have been updated (e.g. by another user on another browser) and the query must then return different data.
As data may always change, why do we avoid network requests when we ask network only?
I think I don't understand some fundamentals maybe, thank you for any help!

[kitten]

Yea, understandable 👍 To put it very plainly: it's not expected that a query gives you data that's always expected to change. Of course, it's imaginable that a query may change on every call if the underlying database changes every time. However, the difference is intent: Does it matter that the data changes every time? Let's say we're Twitter and we query the timeline, we don't care how many calls to the API we make and when we get a response; we display and use the response in the same way, by rendering it to the UI.

If we now take a mutation, it's slightly different; a mutation kicks off a side-effect, meaning that we always expect it to be unique. It matters which result we use, and at what time we get it back. Usually we don't differentiate between "stale" data on mutations or up-to-date data.

This differentiation is a bit tricky because it's a difference beween "regular" effects (e.g. communicating with a database) or a side-effect (e.g. altering the database).

So, it's not a question of whether we avoid network requests, it's more of a question whether we care about what result we get back and when we get it back. Typically, a query can be sent countless times and we could just use the latest results; for a mutation, if we sent repeated calls, we care about each one individually. That's kind of the rule of thumb here, and that's also the difference between what we can consider an effect or side-effect.

In this case it matters because in GraphQL (and hence in urql) we get mutations and queries as a "tool" to do two different things. They have different jobs and purposes in the sense that we communicate an intention here. The intention for a query is to "get things" and the intention for mutations is to "alter or create things". So, in urql there can be an explicit differentiation for instance between what's cached, what's not cached, and whether repeated calls are treated as separate or the same.

[kitten]

@villesau I've created this RFC to make this a little more intuitive in the future: #2184

For now, if you're sending identical mutations concurrently, I recommend you create some kind of altering key for each mutation. As mentioned, this is safe because that's what we do for changing instances, like files, automatically already: https://github.com/FormidableLabs/urql/blob/0b1c3d792b4bd2ca8699f77e06d05aca026926eb/packages/core/src/utils/stringifyVariables.ts#L25-L27

[nandorojo]

For anyone landing here, I used @kitten's suggestion to add a variable to my query which is specific to the hook.

const [skipCache] = useState(() => Math.random().toString(36))

const [query] = useFormInputQuery({
  variables: { id, skipCache }
})

I added a skipCache string variable to my query (which does nothing on the backend). While this is a very rare use case, I am circumventing the cache to get the initial state for a form. The user wants to edit an object from the database, and it's important to get the most up-to-date data for the form state. I wouldn't suggest this methodology in general, unless there is a similarly clear case.

[kitten]

I think this is a different case, and I would not recommend this.

To explain why it's different; above we have a case where upload target URLs are generated, i.e. created. Hence, the suggestion to use mutations, since otherwise given the same input you'll get the same output many times with queries. Even with network-only concurrent or duplicate operations will yield the same result unlike with mutations

In your case however, duplicate operations are fine since you're only retrieving one state. Given that you want the latest state, an imperative client.query call with network-only is actually more desirable given that it also automatically filters out stale results.

Hence, a small effect is preferable for this case or a simple network-only request that treats stale as loading too

[nandorojo]

Hmm I see. Good to know.

For whatever reason, when I set the request policy to network-only, useFormInputQuery returns data: undefined when I visit the form screen for the second time.

The first time I open the form screen, it fetches and returns data properly. But all subsequent visits to the screen just hang. I'll try to repro it and open an issue if I can. The variable option I showed above seemed to fix it, but I wouldn't want to use a solution that isn't recommended.

an imperative client.query call with network-only is actually more desirable

To clarify, are you suggesting I call client.query in useEffect and track it with React state instead of useQuery?

a simple network-only request that treats stale as loading too

The docs say that network-only ignores the cache. Would there still be stale data if I set network-only?

I imagine doing something like this:

const [query] = useFormInputQuery({
  variables: { slug }
  requestPolicy: 'network-only'
})

if (!query.data || query.stale) return <Loading />

return <Form initialValues={query.data.form} />

If that should work, I'll have to investigate why my network-only hook was hanging after it had already been called once.

Second use-case: impersonating users

I have one more use-case for this scenario, and I'm trying to wrap my head around how network-only works. Is there a way to ignore deduping on a hook level, like dedupingInterval: 0 from SWR?

Our admins need the ability to impersonate users on a per-component basis. This is very important for testing and managing our product since it's a two sided marketplace.

The way we impersonate users is by sending a header (headers['Impersonate-User-Id'] = userId).

This is problematic with urql, since the headers don't affect the way the query is stored in the cache.

As a result, if the admin impersonates user A, and then in a separate component wants to impersonate user B with the same query, the results won't be unique to the impersonated user.

My planned solution was to set requestPolicy: 'network-only' whenever an admin is impersonating a user. We want to ignore the cache here, because a query like myBookings { id } has no variables and hence could return the results of a different user.

This is how I'm currently doing this:

const [query] = useMyBookingsQuery(
  useImpersonate(userId)
)

useImpersonate just edits the query options by appending a header (and adding network-only).

import { useMemo } from 'react'
import type * as Urql from 'urql'

type QueryArgs<Variables, Data> = Omit<
  Urql.UseQueryArgs<Variables, Data>,
  'query'
>

export function useImpersonate<Variables, Data>(
  userId: string | null,
  { ...options }: QueryArgs<Variables, Data> = {}
): QueryArgs<Variables, Data> {
  const isAdmin = User.isAdmin(useMyAccount().data)
  const onBehalfOf = isAdmin ? userId : null

  const context = useMemo<QueryArgs<Variables, Data>['context']>(() => {
    return {
      ...options.context,
      fetchOptions() {
        const fetchOptions =
          typeof options.context?.fetchOptions == 'function'
            ? options.context.fetchOptions()
            : options.context?.fetchOptions

        const headers = {
          ...options.context?.headers,
        }
        if (onBehalfOf) {
          headers['Impersonate-User-Id'] = onBehalfOf
        }
        return {
          ...fetchOptions,
          headers,
        }
      },
    }
  }, [onBehalfOf, options.context])

  if (isAdmin && userId) {
    // ignore the cache, since some queries won't always have user IDs to distinguish them
    options.requestPolicy = 'network-only'
  }

  return {
    context,
    ...options,
  }
}

Does this seem like a feasible approach, or am I missing something about how request-policy works? I would again prefer to ignore the deduping exchange for these requests if possible.

When I was using SWR, this was all easy to handle, since I could just pass the userId to the key variable of useSWR. While it wasn't optimal, it helped manage refetching easily.

Sorry this got so long. Thanks again for your help.

[nandorojo]

For my second case, maybe I can just not use the dedupingExchange if the user is an admin. I'd prefer to modify deduping behavior on a per-hook level, but I'm not sure if that's possible.

[gus-t27]

@nandorojo Hey did you figure out the answers to your question above? I am struggling with a similar situation and trying to understand why requestPolicy: 'network-only' is not being respected.

I would like to implement your skipCache solution above but not if it's not recommended 😬

[nandorojo]

We kinda just started doing network only and comparing the returned variables to the used ones. I think it works fine now

[bcupac]

if anyone stumbles upon an issue where they want the query to run every time a submit button on a form is smashed but the query does not re trigger due to the input fields/variables passed being the same, you just have to execute the query manually:

    const [searchQuery, setSearchQuery] = useState(null);

const [{ data, fetching, error }, executeQuery] = useQuery({
	pause: true,
	query,
	requestPolicy: 'network-only',
	variables: { filter: searchQuery },
});

useEffect(() => {
	if (searchQuery) {
		executeQuery();
	}
}, [executeQuery, searchQuery]);

const handleOnSubmit = useCallback(
	(newSearchQuery) => {

	setSearchQuery(newSearchQuery);
		
	},
	[setSearchQuery]
);

return (
   <Search onSubmit={handleOnSubmit} />
)

[nandorojo]

why not just call executeQuery({ requestPolicy: 'network-only' }) in onSubmit?