Changing this option to callOption and passing callotpion here from all places which use this would solve this issue.

We didn't expose call options intentionally because it can be a little tricky to also track those options with the query key (if the call option changes, making sure it also triggers a query, etc). Is there a specific call option you are trying to pass?

@paul-sachs I am trying to pass contextValues from callOption.

So contextValues is one of those things that's hard to track in a querykey since there's currently no way to expose all the values set, and I'm not sure we'd want to trigger a fetch on anytime those context values change. It might help to identify exactly how you're using context to identify a good way we can build context support into connect-query without breaking the reactivity model.

1. Would you be setting this context at the query level?
2. Do interceptors in the web set this context and should that trigger additional fetches?

1. Would you be setting this context at the query level?
   => There is one context that is being used at querylevel which is called NoAuthContext. We use interceptor to automatically add jwt headers on the request. If the value of this context is true then we will skip adding jwt headers to the request.

Do interceptors in the web set this context and should that trigger additional fetches?
=> Yes some of the context are set in interceptors. One of them is a retryCount Context. It does trigger additional fetches.

Hmm I think I understand. We can pass through context values but being responsive to their changes is a little tricky. contextValues themselves don't hook into react reactivity automatically so if you call set anywhere in the interceptors, it won't trigger any change within react.

You can create your own implementation of ContextValues that is perhaps backed by a signals implementation like preact/signals but we'd still need a way to modify the connect-query key to include those values, and ideally, a way to filter those down to only include the keys you actually use in the query.

I'm thinking this could look something like this:

// A hypothetical API
import { createContextKey, useContextValues } from "some-package";
import { useQuery } from "@connectrpc/connect-query";

const kLogBody = createContextKey<boolean>(false, {
  description: "Log request/response body",
});

const SomeComponent = () => {
  const ctxValues = useContextValues([kLogBody]);
  const someQuery = useQuery(schema, undefined, { contextValues: ctxValues });
  ...
}

The above API is purely hypothetical and relies on the relatively new concept of reactive signals but would be compatible with the ContextValues interface provided by @connectrpc/connect.

We'll need to do some investigation to figure out how can break this up into pieces and ideally not absorb a new dependency (like signals).

@ravilamichhane did you find a workaround? We've experimented internally with my solution but it has some quirks that we're starting to think aren't worth supporting. You can still get by with using custom transport with interceptors which set the contextValues.

I needed to pass callOptions for a few mutations — mainly to inject some contextValues our interceptors depend on. So I just modified useMutation to accept callOptions directly. It’s a pretty minimal change and doesn’t affect queries at all, which was nice.

Not clean, but it got the job done.