This is step one towards the migration of milestone handling logic as per #1674. In this phase we add a milestone stage to the processing pipeline to handle milestone transactions as they are received rather than relying on the LatestMilestoneTracker to pull them from the db. This should mitigate the issue demonstrated on devnet, when a node has a high number of milestone transactions present in the db, and it takes a long time to pull them out. New milestones were not being seen and processed fast enough, so to fix that, we handle them straight from the received stage.
This is a follow up to #1821
Fixes #1688
Also relevant to #1448 and #1797
Type of change
Enhancement (a non-breaking change which adds functionality)
How Has This Been Tested?
Existing unit and regression tests have continued to pass with this migration
Checklist:
[x] My code follows the style 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] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
Description
This is step one towards the migration of milestone handling logic as per #1674. In this phase we add a milestone stage to the processing pipeline to handle milestone transactions as they are received rather than relying on the
LatestMilestoneTracker
to pull them from the db. This should mitigate the issue demonstrated on devnet, when a node has a high number of milestone transactions present in the db, and it takes a long time to pull them out. New milestones were not being seen and processed fast enough, so to fix that, we handle them straight from the received stage.This is a follow up to #1821
Fixes #1688
Also relevant to #1448 and #1797
Type of change
How Has This Been Tested?
Checklist: