If a sync is midway through and the node is shut off, it's possible for milestone transactions to get lost in the mix on restart. The transaction object may be present but the milestone object has not been generated. This means that if the node tries to solidify a transaction that references this milestone, it will always skip requesting this transaction as it is already stored.
This stops the milestones from making it into the solidification queue again. By making the TransactionSolidifier request milestones regardless of solidity, and adding an address scanning method for when synchronization stalls out on reboot, we can mitigate most issues that would pop up revolving around syncing and restarting during a sync.
Also lowers the max size of the TransactionSolidifier processing queue to ensure we solidify from bottom up in a more efficient manner.
Type of change
Bug fix (a non-breaking change which fixes an issue)
How the change has been tested
I have started, stopped and restarted many times on mainnet from a Local Snapshot 13k milestones back. Stops and starts resumed syncing in almost all instances.
Change checklist
[x] My code follows the contribution guidelines for this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] New and existing unit tests pass locally with my changes
Description of change
If a sync is midway through and the node is shut off, it's possible for milestone transactions to get lost in the mix on restart. The transaction object may be present but the milestone object has not been generated. This means that if the node tries to solidify a transaction that references this milestone, it will always skip requesting this transaction as it is already stored.
This stops the milestones from making it into the solidification queue again. By making the
TransactionSolidifierrequest milestones regardless of solidity, and adding an address scanning method for when synchronization stalls out on reboot, we can mitigate most issues that would pop up revolving around syncing and restarting during a sync.Also lowers the max size of the
TransactionSolidifierprocessing queue to ensure we solidify from bottom up in a more efficient manner.Type of change
How the change has been tested
I have started, stopped and restarted many times on mainnet from a Local Snapshot 13k milestones back. Stops and starts resumed syncing in almost all instances.
Change checklist