Mutation response fields are unexpectedly null after cache-invalidations.

[schmod]

urql version & exchanges:

    "@urql/core": "2.4.1",
    "@urql/exchange-graphcache": "4.3.6",
    "@urql/exchange-persisted-fetch": "~1.3.4",
    "@urql/exchange-request-policy": "0.1.5",
    "@urql/introspection": "0.3.1",
    "urql": "2.1.2"

Steps to reproduce

We are using GraphCache with an updates configuration that invalidates portions of our cache after some mutations are performed.

However, if the mutation also requests any of those fields, URQL returns a null response for those fields.

For example, with the mutation:

mutation MyMutation {
  updateUserStatus() {
    viewer {
      statusObj { someField }
    }
  }
}

and the cache exchange:

return urqlCacheExchange({
    schema: schema as unknown as IntrospectionQuery,
    keys: { StatusObjType: () => null },
    updates: { Mutation: { updateUserStatus: invalidateStatus } },
  });

function invalidateStatus(_data, _variables, cache, info) {
  if (!info.optimistic) {
    cache.invalidate(getViewerKey(cache), 'statusObj');
  }
}

function getViewerKey(cache: Cache): string {
  return cache.resolve({ __typename: 'RootQueryType' }, 'viewer') as string;
}

...will produce the result { viewer: null }, even when the server returns a full response.
(For the purposes of this example, let's assume that all fields in this schema are non-nullable)

Expected behavior

While we want to invalidate statusObj (to also invalidate any other nested fields that might be in the cache as a result of other queries), we also want to know the value of statusObj that was returned by the server.

Put another way, cache-invalidations should only apply to future queries.

Actual behavior

If a mutation's update configuration invalidates a field returned by that same mutation, the field will is not included in the mutation's response.

---

In a sense, I can rationalize the current behavior – the response is reflective of the current state of the cache. However, my use-case also doesn't seem like it's particularly unique or far-fetched. I want to perform a wide-ranging cache-invalidation after my mutation, but I also still want to know the results of that mutation.

(Also, the above explanation only really justifies why viewer.statusObj might be null – I can't really justify why viewer would ever be null in that scenario)

As I see it, I can see a few ways that this could be addressed.

1. Provide a convenient API to put the fields in the mutation results back into the cache after I invalidate that portion of the cache.
2. Provide a way to make mutation results exempt from caching (ie. mutation results are static and are not updated along with the cache). I think that this would probably be fine (and even desirable) for many real-world mutation use-cases.
3. Get populateExchange to the point where it's ready for production use. This would help to eliminate the need to invalidate caches in the first place.

[kitten]

Noot having a reproduction here makes this a little difficult, but my current suspicion is that both your mutation and queries are referring to a user entity, correct?

The problem here seems to me not that the result is changing, which it must consistently according to your schema and config. What I don't understand here is the purpose though of this invalidated field and entity. If you're invalidating it it must either be refetched or is missing, so I'm not sure if invalidating here is the wreong choice?

In other words, since I don't understand the meaning and intent of your schema, mutation, and scenario just by looking at the snippet it's hard to reconcile what yoour schema looks like, what the expected behaviour is, and what an alternative may be, if any apply

we also want to know the value of statusObj that was returned by the server.

that's basically the problem I have. If your mutation invalidates this field and also delivers this field, how is that consistent with what's expected? If your mutation is both changing it but also making "its own data invalid" then I don't see how it could deliver the value 😅

Edit: I just wanted to follow up on one statement so we're on one page ✌️

While we want to invalidate statusObj (to also invalidate any other nested fields that might be in the cache as a result of other queries), we also want to know the value of statusObj that was returned by the server.
Put another way, cache-invalidations should only apply to future queries.

The thing that doesn't make sense to us is two-fold. We only have one target entity here that's being modified and presumably occurs in both the mutation and query. Inherently, to be consistent we may only modify one and the same identity of the entity.
Now, when you invalidate this shared data, you're explicitly also updating the mutation, since you're telling it what to "throw away".

I think what I then struggle to understand is, if your mutation has just given you this field, why are you invalidating it? The mutation already delivers it and then you're trying to immediately refetch it?

[smontlouis]

It seems like I'm having a similar issue, so please don't hesitate to tell me if I need to create my own.

I have the following schema provided by strapi graphql, basically notes containing tags.
(Regarding the schema, I need to silence as a non-keyable entity UserTagEntityResponseCollection, UserTagRelationResponseCollection:, UserTagEntityResponse, UserTag)

userNotes(
  filters: UserNoteFiltersInput
): UserNoteEntityResponseCollection

type UserNoteEntityResponseCollection {
  data: [UserNoteEntity!]!
}

type UserNoteEntity {
  id: ID
  attributes: UserNote
}

type UserNote {
  user_tags(...): UserTagRelationResponseCollection
  content: String!
}

type UserTagRelationResponseCollection {
  data: [UserTagEntity!]!
}

type UserTagEntity {
  id: ID
  attributes: UserTag
}

type UserTag {
  name: String!
  description: String
}

and the following query:

export const GET_USER_NOTES = gql`
  query userNotes {
    userNotes {
      data {
        __typename
        id
        attributes {
          content
          user_tags {
            data {
              id
              attributes {
                name
              }
            }
          }
        }
      }
    }
  }
`

While in a note, I can delete a tag, and I want it to be deleted in every note.

deleteUserTag: (result, args, cache, info) => {
  cache.invalidate({
    __typename: 'UserTagEntity',
    id: args.id,
  })
},

So let's say I'm on note 73, and I delete a tag, the whole user_tags object get deleted for the other notes.

{
    "userNotes": {
        "data": [
            {
                "__typename": "UserNoteEntity",
                "id": "73",
                "attributes": {
                    "content": "super test",
                    "user_tags": {
                        "data": [
                            {
                                "id": "67",
                                "attributes": {
                                    "name": "tag_one",
                                    "__typename": "UserTag"
                                },
                                "__typename": "UserTagEntity"
                            },
                            // correctly deleted
                        ],
                        "__typename": "UserTagRelationResponseCollection"
                    },
                    "__typename": "UserNote"
                }
            },
            {
                "__typename": "UserNoteEntity",
                "id": "74",
                "attributes": {
                    "content": "Lorem ipsum",
                    "user_tags": null, // Whole object gets deleted
                    "__typename": "UserNote"
                }
            },
            {
                "__typename": "UserNoteEntity",
                "id": "75",
                "attributes": {
                    "content": "Popo",
                    "user_tags": null, // Whole object gets deleted
                    "__typename": "UserNote"
                }
            },
        ],
        "__typename": "UserNoteEntityResponseCollection"
    }
}

[JoviDeCroock]

@bulby97 the whole object didn't get deleted, the UserTagEntity has been trasnformed to null and your schema indicates that that's not possible [UserTagEntity!]! the ! behind UserTagEntity is telling us that we can't accept null as a value here. This means that it will bubble up because the entity is invalid which makes user_tags the first nullable entity and hence transformed to null.

If you want to completely evict the entity from an array it will probably be easier to use updateQuery

[smontlouis]

@JoviDeCroock thanks for your answer,

Is this because I'm using schema awareness ?
First I thought invalidating an entity would just trigger a refetch for the impacted queries, but I read this in the docs :

If we're using ["Schema Awareness"](https://formidable.com/open-source/urql/docs/graphcache/schema-awareness/) then these queries' results may actually be temporarily updated with a partial result, but in general we should observe that queries with data that has been invalidated will be refetched as some of their data isn't cached anymore.

And ironically, if I disable schema awareness, everything is working correctly.

Using updateQuery might be a little complex since I have way more entities having tags, but I can do it if necessary

[schmod]

TBH, I've found partial results to be pretty bothersome to work with. You basically need to assume that any field in your schema could suddenly become nullable at any time, independent of everything else.

[kitten]

You don't have to use Graphcache's schema awareness in that case, but the important bit here is: if you mark an object as nullable, you'll have to expect it to become nullable, no matter whether you use Graphcache or not, since they also represent optional data and error boundaries for resolvers.

That said, there's also a proposal for nullability operator for this purpose

[arb]

I realize this is an old discussion, but I'm having the identical problem as @schmod. As he said, this is a pretty common use-case (update the DB and then return whatever the update was so the client can be informed of the changes). While I can understand conceptually why viewer.statusObj could be null, I don't understand why the entire viewer object would be null.

I'm currently working around this by doing a second fetch to get the updated information but that's more of a work-around when the mutation returns the data we want and isn't an efficient solution.

This was marked as the answer but it doesn't provide a path forward on how to fix or adjust the use of urqlCacheExchange to mitigate this problem. Are there any additional ideas or suggestions we could try?