The list of transactions can be queried afterwards and it is currently flooding the log files. I may consider putting it back once we have a log parser, but it seems pretty unnecessary.
The sleep flag was used to avoid doing useless work when no data was hold by the tower. However, from the implementation of the data persistence on, the Watcher and Responder should at least keep track of the last known block. The current apporach was making this harder.
- Uses an instance of the Carrier so it can benefit from issued_receipts and avoid resending multiple copies of the same triggered appointment
- Defines last_known_block to properly load data from db
- Uses task_done from Queue to properly signal task completion when boostraping from db
- Creates a checked_txs dict in get_completed_trackers to avoid querying bitcoind for the same transaction over and over
- Redefines completed_trackers as dict instead of tuple
The Watcher and Responder were not properly bootstrapped from db data if both were missing blocks to process. Since some appointments may need to pass from the Watcher to the Responder during this process, they need to be brought up to date at the same time, block after block.
Data obtained from the database was not properly handled in some cases:
- If some appointments are accepted and no block is received and the tower is restarted, the data was not loaded. The tower was checking that the Watcher/Responder had a last known block, which may not have been the case. Now best_tip is set as last_known_block on a fresh bootstrap.
- The Watcher/ Responder were not being awaken when loading data from the database.
- The block queues were not properly populated
- The builder was never modified when the in-memory data was reduced, so it was still trying to build data based on the past approach.
- Renames create_block_queue to poplate_block_queue and repurposes the method
When creating a block queue, a new Queue was created and populated. That was breaking the link between the Watcher/Responder and the ChainMonitor since the Queue is defined beforehand.
Logger was only used to log when a new folder was created, and was making that the setup needed to be done on the main of pisad and cli instead of __init__, which seems a better fit
The setup of the logs and the parsing of the config file are closely related. The former need info from the later to be created, and needs to be setup only once
per pisa instance. In the same way, the later need to only be loaded and validated once per pisa intance and contains info to setup the logs.
Intead of setting up the logs in init and loading the config file in pisad, now both are dealt with in __init__
When an appointment was triggered a flag was set in the Watcher, and removed later on in the Responder if the transaction ended up being rejected. That's pretty annoying. Since we have information about whether a transaction has made it to the mempool or not via the Carrier's receipt, this can be all done in the Watcher, which makes more sense and reduces the interaction with the db (1 write if succeeds, 0 otherwise instead of 1 write if succeeds, 2 otherwise).
- Refactors store_update_locator_map name to create_append_locator_map, which is a better fit.
- Adds update_locator_map method to update maps by removing some uuids (store_update_locator_map was not covering this, what was misleading).
- Adds missing docs.
- Improves code modularity.
- Separates flag_triggered from delete_appointment, which was pretty misleading (and causing some minor bugs) and make them work with lists intead of single objects.
- Removes unused import
There was a bug in the Responder where, if a tracker could not be added (e.g. malformed tx) the data was dropped but never removed from the Watcher's db. This is due to flagging appointments as triggered instead of deleting them from the Watcher's db straight away (in order to deal with reorgs in the future).
If that approach is not followed, and appointments are removed from the Watcher's db once they are passed to the Responder, this should be removed since it would be redundant.
