How to rewrite cursor-based pagination using field policies when queries are nested?

I have a client who is using @apollo/client@3.5.8 and they were seeing some wonky behavior with the query surrounding their infinite scroll feature. Doing some digging on it the first thing I saw was this deprecation message:

react_devtools_backend.js:3973 The updateQuery callback for fetchMore is deprecated, and will be removed
in the next major version of Apollo Client.

Please convert updateQuery functions to field policies with appropriate
read and merge functions, or use/adapt a helper function (such as
concatPagination, offsetLimitPagination, or relayStylePagination) from

The field policy system handles pagination more effectively than a
hand-written updateQuery function, and you only need to define the policy
once, rather than every time you call fetchMore.

When commenting out the fetchMore code the problem they were seeing goes away (at the expense of losing infinite scrolling). I have been reading through the Cursor-based Pagination Docs since that is how their query works and I am having trouble wrapping my head around if what they have going on is going to be possible to update or if it will need to be refactored into a different architecture for querying.

The client has a top-level query that fetches a user profile and from within the query another query for that user profile’s things the things query has several arguments allowing it to be a highly configurable query for the user’s things. Below is an example of the query that is happening on the page and the beginnings of defining the field policies.

query ThingsPage(
    $after: String
    $before: String
    // ...
  ) {
    profile: getUserProfileById(id: $id) {
        after: $after
        before: $before
        // ...
      ) {
        pageInfo {
const client = new ApolloClient({
    cache: new InMemoryCache({
      typePolicies: {
        Query: {
          fields: {
            getUserProfileById: {
              keyArgs: false,
              merge(existing, incoming, opts) {
                return existing
              read(existing, opts) {
                return existing && existing

My Questions

  1. How do I get access to the things query that is happening internal to getUserProfileById? If that is even possible?
  2. Is the current query maintainable if this is possible or would doing surgery and splitting this query up be a more feasible option not just from a DX perspective but also a performance and functionality perspective?

Thank you for your help, it has been a hot minute since I have used Apollo and I’m trying to get up to speed quickly with it.