When the transaction solidifier was introduced, we updated how transactions are passed through to broadcast, and under initial review we opted to fetch broadcast transactions at the end of the solidification stage, to pass them forward to the broadcast stage in the event the original solidifying transaction is not solid. This sequential loading of transactions from the broadcast queue does not forward transactions fast enough. To correct this, the logic has been moved to the broadcast stage instead. The broadcast stage will complete the transaction forwarding as it was previously designed to do, and the broadcast stage will check if a transaction still exists to broadcast, and if there is, it will pass it to the broadcast stage queue until there is nothing left to pull out of the set.
Fixes an error that occurred in high tps environments that would cause a delay in the forwarding of transactions via broadcast
Type of change
Bug fix (a non-breaking change which fixes an issue)
How Has This Been Tested?
Using the same topology that the problem was first observed in (within the ICC network) transactions, specifically milestone transactions, are being forwarded in a timely fashion.
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] New and existing unit tests pass locally with my changes
Description
When the transaction solidifier was introduced, we updated how transactions are passed through to broadcast, and under initial review we opted to fetch broadcast transactions at the end of the solidification stage, to pass them forward to the broadcast stage in the event the original solidifying transaction is not solid. This sequential loading of transactions from the broadcast queue does not forward transactions fast enough. To correct this, the logic has been moved to the broadcast stage instead. The broadcast stage will complete the transaction forwarding as it was previously designed to do, and the broadcast stage will check if a transaction still exists to broadcast, and if there is, it will pass it to the broadcast stage queue until there is nothing left to pull out of the set.
Fixes an error that occurred in high tps environments that would cause a delay in the forwarding of transactions via broadcast
Type of change
How Has This Been Tested?
Using the same topology that the problem was first observed in (within the ICC network) transactions, specifically milestone transactions, are being forwarded in a timely fashion.
Checklist: