Open sr-gi opened 5 years ago
Comments on this would be appreciated @stonecoldpat @yahgwai @bigspider
For the record, the current approach to deal with bootstrapping from backed up data consist in simply find what blocks have the watcher and responder missed whilst offline, instantiate them with their old state, and hand them all the blocks so they can run as if they had just received all that info.
The main idea is to call find_last_common_block
, rewind_states
and get_missed_blocks
and feed the rewinded_states and missed blocks to both the watcher and responder (load_prev_state
)
I may separate this from 9-add-data-persistency and add it to a later release. Focusing on data persistency without forks for now.
Bootstrapping from backed up state may end up in the watcher/responder having to deal with reorgs that happened when they were offline.
In order to deal with this, we will store a list of last known blocks (e.g: 30-40 hashes) so we can find what's the last common block, backtrack, and get the new information.
The watcher should be able to run with no much trouble, if a reorg happens finding the last common and build from there should be enough to catch all the possible triggers, and invalid appointments (those that may have been included in an orphan branch) will eventually expire.
The responder is more complicated though. Some jobs may have a different confirmation counter (easy to deal with) whereas other may be valid no more. For the later case, we may need to add those back to the watcher so they are handled.