For context - Conflicts may be resolved on either the server side or on the client side.
In the ideal scenario, when When a conflict is resolved on the server side the newly resolved and stored record should be returned to the client alongside a Conflict error. This lets the client know there was a conflict on the server side, it was resolved and here is the new data. The client can act accordingly and update its cache/UI/etc. This is fairly simple.
A developer can also choose to not handle any conflict resolution on the server side. In this case, the server will respond with both a conflict error and the current most up to date record stored in the database. The client can then choose how to deal with the conflict. This will involve resolving the data on the client side using a handler (generic or custom) and then sending a new mutation back to the server.
The simplest flow here would be
* The client tries to modify v1 of a record
* The record in the database is actually v2 so the server responds with a conflict error and the v2 version of the object from the database
* The simplest way to handle it on the client is to simply retry the mutation but with the correct version.
Hopefully this flow makes sense and now it's obvious that we need to build some sort of retry logic within the client SDK to handle this case. It's possible that the mutation will fail for many reasons (network, timing, a new conflict, etc). We need to be able to retry the mutation and have some parameters on that such as max number of retries. We also need to persist those pending mutations so they are not lost across app restart. |
|
