Should custom updates triggered by optimistic mutation be repeated?

[codazzo]

Hi! First of all thanks for your support so far 🙏

As I mentioned in some previous discussions (repeating here for reference) I'm trying to support a scenario whereby users of a native app would be able to create some "Recommendation" entities while the device is offline.
I'm using @urql/exchange-graphcache's offlineExchange, with an optimistic mutation and a custom updater which updates a query which lists recommendations

offlineExchange({
    storage, // <--- I created this using AsyncStorage
    schema,
    updates: {
        Mutation: {
            createRecommendation: (result, args, cache, info) => {
                const recommendation = .... // builds recommendation from args
                const fieldId = ... // gets field Id from args

                cache.updateQuery({ query: QUERY_RECOMMENDATIONS, variables: { fieldId } }, (data) => {
                    data.recommendations.push(recommendation);
                    return data;
                });
            },
        },
    },
    optimistic: {
        createRecommendation: ... // creates a Recommendation entry with a temporary ID
    }
});

Everything is working as expected except maybe one thing which I though I would report.
Suppose the device is offline, and I create a Recommendation. The optimistic mutation runs, followed by the custom updater. After this QUERY_RECOMMENDATIONS has these entries

[
  { "id": "temporary_id_001" }
]

At some point the device goes back online, so the mutation that was saved as "pending" in the offlineExchange's queue gets re-executed. We again run the optimistic mutation and the custom updater. At this point QUERY_RECOMMENDATIONS has these entries

[
  { "id": "temporary_id_001" },
  { "id": "temporary_id_002" }
]

The mutation is successful as the device is online, so when a successful response is returned from the API the custom updater runs again. At this point QUERY_RECOMMENDATIONS has these entries

[
  { "id": "1144cee7-5d0d-4589-a26c-e1322e429b2d" }
]

For a very brief time (between when the second optimistic mutation is applied and when the response come back from the API) the query has two entries for the "createRecommendation" mutation, but the user only ever meant to create one.
What I see on a "Recommendations list" screen is a brief flickering between 1 reco, 2 reco, 1 reco when the device gets back online.

I implemented a workaround whereby I assign a random number to the mutation's payload and when the second optimistic mutation runs I check in the custom updater whether an entry already exists in the cache with that random number. If one exists, I return from the updater. This solves the issue with the flickering.

I nevertheless thought I would open this discussion as conceptually I'm not sure we should run the optimistic mutation twice as it would cause a brief inconsistent state unless the mutation is "idempotent". Would it make more sense to run the optimistic migration once when the device is offline, and then when the device gets back online we only apply the custom updater on the actual response from the API?

[kitten]

Oh interesting! Can you convert this into a bug report please (I think there’s an option in discussions for that)

The previous data of the optimistic layer is supposed to be invalidated by the repeated mutation.

[codazzo]

Opened an issue at #1079

I would have been glad to create a code sandbox for this but unfortunately I can't think of a way to simulate the offline/online scenario.

[frederikhors]

With the browser devtools Offline/Online checkbox perhaps?

[kitten]

Locking this thread, since the discussion can be moved there 👍
Luckily this won't need a reproduction as our code is pretty explicit around data layers, meaning I can exactly see the lines responsible for a repeated optimistic update and was then able to see that the behaviour I expected to be there isn't actually there.