How to architect: local resolver re-populates from ssrExchange

[frantisek-heca]

We are running Next Pages Router app, having getServerSideProps.
The first time user visits a product page, the ssrExchange populates correctly the client's cache with ProductQuery.
The consequtive visits of the same product, the getServerSideProps is designed by us to send a fresh ProductQuery in the ssrExchange.
But it's not needed/used, the cached version is already present...

Which was ok until we we wanted to have fresh data from the ProductQuery on each visit.
I tried to use local resolver and return undefined (for the ProductQuery).
Thinking that the ssrExchange will provide the already present ProductQuery.

But somehow it's not working.
When I debug naively the source code...
It seems after returning undefined from a resolver, it does trigger the ssrExchange data correctly.
But then it tries to updateCacheWithResult and inside it does _query (queryResult) the same ProductQuery and the resolver is triggered again and returns undefined and it loops in this pattern.

Any ideas, advice, please?
I cannot play with (work with) ssrExchange cache from resolvers, right?

[MILLERMARRU]

I read through ssrExchange's actual source (packages/core/src/exchanges/ssr.ts) because your first symptom, "consecutive visits send a fresh ProductQuery in ssrExchange but it's not used, the cached version is already present", is explained entirely by ssrExchange itself, before resolvers even enter the picture.

ssrExchange is explicitly documented (and implemented) as one-shot:

// On the client we delete results from the cache as they're resolved
cachedOps$ = pipe(cachedOps$, tap(invalidate));

const invalidate = (result: OperationResult) => {
  invalidateQueue.push(result.operation.key);
  if (invalidateQueue.length === 1) {
    Promise.resolve().then(() => {
      let key: number | void;
      while ((key = invalidateQueue.shift())) {
        data[key] = null;
      }
    });
  }
};

The moment a query is served once from the SSR cache on the client, its entry gets set to null (not deleted, set to null specifically). That matters because restoreData checks for exactly that:

ssr.restoreData = (restore: SSRData) => {
  for (const key in restore) {
    // We only restore data that hasn't been previously invalidated
    if (data[key] !== null) {
      data[key] = restore[key];
    }
  }
};

So once a given operation key has been served and invalidated, any later restoreData(freshPageProps.urqlState) call for the same key (e.g. on your second visit, from a fresh getServerSideProps) is silently a no-op, data[key] is already null, so the guard rejects the new payload. That's the real mechanism behind "it's not needed/used", it's not that urql is choosing the graphcache cache over the SSR one, it's that ssrExchange's own internal cache has already permanently discarded that key and refuses new data for it.

Given that, trying to make a local resolver "peek into" the SSR cache is fighting the exchange's design rather than working with it, ssrExchange sits ahead of your normal cache in the exchange chain specifically as a one-time replacement for the network request, it was never meant to be a source of truth resolvers can repeatedly pull fresh data from. The loop you're seeing (resolver returns undefined → graphcache's updateCacheWithResult re-queries → resolver runs again → undefined again) is graphcache trying to resolve the query from its own cache after your resolver opted it out, and finding nothing there either since there was never a real network result for graphcache itself to store, only the transient SSR replay.

The two practical paths that actually work with how ssrExchange is designed:

1. Use requestPolicy: 'network-only' on the repeat visits where you explicitly want fresh data, bypassing both ssrExchange's cached branch and graphcache's document cache entirely, no resolver needed.
2. Don't rely on ssrExchange for anything beyond the very first hydration. Since it's designed to be discarded after one read, treat the SSR payload purely as "avoid a duplicate network request on first paint", and let graphcache's normal cache-first/cache-and-network policies handle subsequent visits based on what's actually in the persistent cache, not ssrExchange's throwaway one.

If you specifically need "cached instantly, but always double-check network in the background", cache-and-network as your request policy on the query itself replaces what you were trying to build manually with the resolver.