-
Notifications
You must be signed in to change notification settings - Fork 32
Description
There is a feature in the code that was introduced to defend us against losing a track of executed payments if the software crashes just after we send them out. While we are still in the process of preparing the transactions we collect the transactions attributes including their hashes. That enables us to put up descriptive records mirroring the txs and insert them in our database. As already stated, it's viable to do it before we proceed to point of sending the payments. Because it was pointed out this should not become an agenda of the BlockchainBridge itself, we send these records from here by an Actor message to the Accountant which will see about persisting them in the DB. This is, however, the weak spot of the design that we're trying to unveil by this card.
This card is about a race that occurs because the BlockchainBridge acts as if it was given that the sent payable records are protected after it sends the Actor message with their mirrored records. However, it is not so. We should correctly pause in the BlockchainBridge until it is guaranteed. Instead, the BlockchainBridge rushes to complete the job, and sends the request containing the blockchain transactions headless. There's no guarantee that the Accountant managed to save the records though. Most likely it never does.
Design note:
This card should probably wait until the We're Falling Behind! card is played (#GH-676). The modernized actix is more centered in the async message-processing. It makes writing this type of solution much easier and as the technique goes convenient globally in the Actix ecosystem. We'll send a message and immediately register us for waiting for its response. This will happen asynchronously, powered by the Actix runtime.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status