readQuery cache misses after other query for same type

Help
,
1

I have a query GetTrip which returns a fully populated Trip object. A view in my UI uses a GetTrips query to grab a list of much lighter Trip objects (basically name and id). After this second query is executed, readQuery(...) will fail for my GetTrip, returning null. Looking at the cache using the Apollo devtools I see that the Trip is there and fully populated, so I think Apollo’s properly merging the full one with the partial one. What else could cause the cache to miss?

Fragments and queries:

  fragment ListTrip on Trip {
      id
      name
    }

  query GetTrips {
     trips {
       ...ListTrip
     }
   }

  fragment Trip on Trip {
      id
      name
      // (a ton of other fields)
  }

  query GetTrip($id: ID!) {
      trip(id: $id) {
        ...Trip
      }
    }

If I swap out the light fragment in GetTrips for the full fragment, Apollo correctly finds and returns the trip.

Thanks!

2

Could you please post some more info about your setup? Stuff like your cache config/type policies, query options passed into useQuery, how you’re calling readQuery, etc

3

Sure! My cache is just a regular in memory cache, no special config. Query options are just using the default CacheFirst policy.

I’m calling readQuery using the cache returned from a mutation in the update function:

const trip = cache.readQuery({
  query: TripHooks.GetTrip,
  variables: {id: tripId},
});

This call will succeed every time until I trigger the GetTrips call that returns the partial data. Then it will return null rather than the trip.

4

I found I can disable the cache for my GetTrips query, which will keep it from breaking the GetTrip. That’s not ideal, but it’s a light query and really fast, so it’s a lot less painful than the cache miss for GetTrip.

5

Sorry, I can’t see anything here that would cause that behavior :frowning:

6

Does cache.readFragment do any better than cache.readQuery?

7

Same as readQuery sadly. No worries if nothing else comes to mind- the workaround disabling the cache for the other query is pretty painless for now.