Create Generic Transactions to Bundle Async Operations

[vijayee]

Problem

When async calls fail the leave the application in an invalid state

Solutions

Create a Generic Transaction object that can be use to bundle async operations together in a way that can be resumed when an error occurs. If an error occurs the failure should save the transaction state in the database to be resumed later.

[taoeffect]

Notes:

• this might not need to necessarily be an "object", but could just be function calls like "beginAsyncTransactions" / "revertAsyncTransactions", etc.
• it's fairly easy to save the vuex state, but other state that isn't part of the vuex state should be carefully and systematically handled too, this includes: socket connections, pub/sub subscriptions, and individual component data/state

In the meantime, please add // TODO:s in appropriate places in the code where this needs to be done, referencing this issue.

Edit: also useful: https://www.cs.utexas.edu/~lorenzo/papers/SurveyFinal.pdf

[taoeffect]

Also note this goes hand-in-hand with #175 — Error notification system.

[taoeffect]

OK, so basic psuedocode + notes from the call on how this is done:

Pseudocode

In the .vue files, for every "submit"-like action that has a series of asynchronous call steps and publishLogEntry steps, we do the following:

1. We split up the async calls and the publishLogEntry stuff into two sections, with the async calls being done first, and the publishLogEntries being done only if all the async calls succeeded.
2. For the async calls: before doing any of the async calls, we create a saved snapshot of the vuex state. If any of the async calls fails: we revert the app to that saved snapshot, we display an error message to the user, and we do not proceed to the publishLogEntry section.
3. If all the async calls succeeded, we build up a series of serialized actions that are to be added to a queue, as well as the names of any "services" that they might need to create the Events/Entries to be published. This "saving of service names" part is called "dependency injection", and we do it because, for example, we might need the latest hash of the group log before we send any message, and that might change if something failed on our end, and someone added something to the log in the meantime. So, all of these actions, corresponding data, and corresponding services, are placed into an array that will be added to the queue. For other information that's stored with these actions, see notes below.
4. Add this array of actions to the queue.
5. The queue itself then goes through the actions, and it, and only it, calls publishLogEntry. No place else in the code should call publishLogEntry (as far as I can tell)

Notes

• Each action that's added to the queue will probably be an object, that besides containing the data and services needed for creating that event, could have a key containing information about various parts of the UI that are disabled until this action/event is successfully sent out to the server.
• In order to make the "revert vuex state" stuff work correctly, we need to tie the Pubsub to the vuex state by having the Pubsub maintain a list of websockets it has open, and have the vuex store also contain this same list in it under a key called "pubsub". Then have the Pubsub watch the vuex store for any modifications to that key. For example, if the vuex "pubsub" key has 1 item in it that the Pubsub list does not, then the Pubsub takes that to mean that it should open a websocket connection. If the vuex list does not have an item that the Pubsub does have, then the Pubsub takes that to mean it should unsubscribe/close the websocket.

Examples

Examples of sections that would be converted to using this method include:

• https://github.com/vijayee/group-income-simple/blob/1818f7da5104a1eb29fd4a4f79e6ee3daeda6c42/frontend/simple/views/Join.vue#L128-L146
• https://github.com/vijayee/group-income-simple/blob/1818f7da5104a1eb29fd4a4f79e6ee3daeda6c42/frontend/simple/views/SignUp.vue#L89-L119

[taoeffect]

Per today's convo, it turns out the that handling the first type of "revertable transactions" (i.e. the "asynchronous call step" part) is not necessary, and in fact trying to save+revert state would break things in the event that a handleEvent modified the state in between.

So it makes sense just do nothing about that, and the async backend.subscribe calls are instead being handled automatically by keeping that pubsub system in sync with the vuex store (issue #298).

Therefore this issue and any related PRs is just about the 2nd type of transactions, the ones that modify external state / the log (i.e. the ones calling publishLogEntry). Nothing should be done regarding the first type (the local async actions).

[taoeffect]

4. Add this array of actions to the queue.

Hmm, we should make sure to first serialize this array to disk before doing anything else, and to do so in a manner that guarantees that all the steps are serialized correctly (and not say, 2 out of 3 steps before data corruption caused by power failure).

To do that we can hash the steps together in a json blob and save them to the database along with the hash of the blob. If upon deserialization the hash doesn't match the blob, then we know something got corrupted and the entire series of steps should be tossed out.

Also:

Each action that's added to the queue will probably be an object, that besides containing the data and services needed for creating that event, could have a key containing information about various parts of the UI that are disabled until this action/event is successfully sent out to the server.

PR #320 needs to not forget about handling that part ☝️

See especially this review comment

[taoeffect]

Think this isn't necessary anymore.