kphfb
commented
3 years ago Versioning exists on an individual basis on objects and isn't a global version. Which means that for TR specifically, it's of little importance actually (or at least not any more importance than someone losing their entire DB which is already fairly painful, but doesn't prevent communications from continuing). If this were a global state, then you are correct that it would break the channel. Let's take an example and explore what happens:
- Two VASPs, C and D
- C creates a TR object with state of abcd and sends it to D who responds with OK. This request would have _reads empty because it reads nothing and _writes of abcd since it writes the object state for this one object as abcd
- D (or C) loses their entire DB
- C creates another TR object for a new transaction. It has _reads empty since this is a new object and hence not dependent upon any prior state of this object. It has _writes of cbad for this new object. D is able to handle this fine because what it cares about is that it has the object state contained by _reads. Since _reads is empty, it means that this command has no prior dependencies.
- C tries to update the first object abcd. It sends a command with _reads of abcd and _writes of 1234. This will fail since D no longer has this state due to the dropped database. C will need to re-create this object if they wish to submit it on-chain (or D will likely refund it if it's submitted on-chain). So there is a set of transactions that will have issues, but it's fairly short-lived. Essentially only objects which were open at the time that the database was dropped (assuming there was no backup from which to restore).
As you can see, there isn't actually a requirement to know that you had a channel with a VASP previously in the case that you lose your database since the only thing that you lose is open transactions which can be re-instantiated when the sending party sees an error response. We considered a state synchronization, but since these are individual object states, the scope of the failure is pretty limited and the advantage of simplicity vs preventing all failures felt like a reasonable tradeoff.
dahliamalkhi
gdanezis
What happens if one of the parties loses synchronization?
Scenario 1 - Server out of sync? The protocol server sends a command to the protocol client and ask to mutate an object. The command _reads object version 1 in an attempt to write version 2 while the protocol client possess version 5 in such cases what should the client do? fall back to the server version?
Scenario 2 - Client out of sync? The protocol client sends a command that reads object version 1 and willing to mutate it onto version 2. The server the last version is already version 5. In that case, since the server is the source of truth how the client is supposed to fetch the diff and resync it's channel state? (versions 2-5)
Scenario 3 - One of the parties lost channel state completely (disaster recovery)