Problems with query update when using optimistic updates with nested response

[rodogir]

Hello,

I've been debugging an issue with one of my queries not updating correctly after a mutation change. I am using urql with React, the graphcache exchange and optimistic updates.

I have a form that allows editing of customers. Each customer can have an arbitrary number of contacts. Each contact can have an arbitrary number of emails. They are all separate entities with an ID.

I use a single mutation field to update all entities at once. It works like an upsert. Entities that are sent with an ID are updated, those without one are inserted.

In addition to that, we also use optimistic updates. And this is where my problems start.

First, the query is not updated and doesn't return the new values after the mutation result is applied. The optimistic update and the mutation result do cause a render. I can see though, that the cache has updated its internal data structure. By disabling optimistic updates, the problem is fixed.

Second, the query not updating only happens under certain conditions. If I add a new contact to an existing customer, the update doesn't work. If I add a new email to an existing contact it does work.

Third, once the query fails to update it will never update again. Even if I trigger a different mutation that changes a customer field, it won't update the view. I can see that the cached values have changed.

It seems that the query gets disconnected from the cache.

Here is the diff of the optimistic result (left) and the actual response (right). Note, that I am using temporary ids for the entities that will be created.

And here an example of adding a new email (which updates the query). Left: optimistic result, right: actual result

I also tried manually invalidating the cache of the mentioned query. Even then, the query doesn't update but again, I'm able to see that the changes have been applied to the cache.

I'm at a point where I don't understand why this happens and why it only happens in certain cases.

How can I solve this and keep the optimistic updates?

[kitten]

I also tried manually invalidating the cache of the mentioned query. Even then, the query doesn't update but again, I'm able to see that the changes have been applied to the cache.

So this does sound a little odd. So your changes have been applied but the hook isn't reflecting that? Are you using the React bindings? If you're using suspense have you upgraded them recently?

[rodogir]

Exactly, the changes have been applied to the graphcache but the hook does not return the new data. Nor does it return the old data. It just doesn't do anything. No render is triggered.

I'm using the React bindings (urql@1.11.3) and @urql/exchange-graphcache@3.3.4 and I don't have suspense enabled.

[kitten]

Ok, this isn't 100% guaranteed, but have you tried your code against the new versions of either of these packages?

• Graphcache has just had a fix for query result updates that may be influenced by this; although I can't 100% say whether this is the same edge case https://github.com/FormidableLabs/urql/blob/main/exchanges/graphcache/CHANGELOG.md#340
• I first suspected that this may be related to this fix in urql for React, however this only applies to suspense https://github.com/FormidableLabs/urql/blob/main/packages/react-urql/CHANGELOG.md#1115

[rodogir]

Thanks for the suggestions. Updating to the latest versions did not solve the issue for me.

I could try to create a codesandbox example, but I would need to mock the graphql api somehow and enforce the same responses I am seeing. Any ideas how I could achieve that efficiently?

[rodogir]

I got it working now. Though the behavior is still strange. While looking at my query and the mutation I noticed that I had one field in the query that was not present in the mutation. Here's the full query and full mutation as a reference.

query CustomerDetails($id: bigint!) {
  customerByPk(id: $id) {
    id
    name
    state
    notes
    updatedAt
    contacts {
      id
      name
      isPrimary
      customerId
      emails {
        id
        email
        isPrimary
      }
      phones {
        id
        phoneNumber
        isPrimary
      }
    }
  }
}

mutation UpdateCustomerDetails(
  $object: customers_insert_input = {}
  $on_conflict: customers_on_conflict
) {
  insertCustomer(object: $object, on_conflict: $on_conflict) {
    id
    name
    notes
    updatedAt
    contacts {
      id
      name
      isPrimary
      emails {
        id
        email
        isPrimary
      }
      phones {
        id
        phoneNumber
        isPrimary
      }
    }
  }
}

Notice, that the query requests the customerId field for every contact. The optimistic update did not include the customerId field in the return value as I modeled it after the fields requested by the mutation.

So, the solution in this case was to simply remove customerId from the query. Now everything is working as expected.

It still strikes me as odd, that the same response breaks when using optimistic updates, but works when returned from a mutation.

Also, if I omit any customer fields from the optimistic updates (e.g notes) the optimistic update still works when adding new contacts.

[kitten]

Alright, that's indeed a little odd; I'll have to read this more closely but it sounds like both; a warning is not being issued as it should, and this should still issue a new version of the query's data.

[kitten]

Ok, I took another look at the difference between the two. The interesting thing here is that your query has the additional field; I'm assuming that your updater adds to that list and the field is missing.
This means that the query won't be able to read the field from its cache.

This is probably pretty detrimental without schema awareness as it won't be able to re-render the query at all during the optimistic update phase.

Can you confirm however that the query refetches after the mutation completes? If not then that's definitely a bug.

I think what we can do here is warn about cache misses that happen on queries using optimistic data in development. That may be a tricky warning to add though as it may be prone to misfiring 🤔

[rodogir]

No, the query does not refetch after the mutation completes. Once this happens it never refetches. Even after triggering a different mutation without optimistic updates that also affects the query.