-
Notifications
You must be signed in to change notification settings - Fork 471
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make proposal assembly time configurable #3165
make proposal assembly time configurable #3165
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3165 +/- ##
==========================================
- Coverage 43.79% 43.79% -0.01%
==========================================
Files 392 392
Lines 86880 86881 +1
==========================================
- Hits 38050 38048 -2
Misses 42799 42799
- Partials 6031 6034 +3
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! I was trying to think of any use cases where agreement would have information it would want to use to set a deadline for AssembleBlock, though we're not doing this today.
When agreement enters a new round, the "assemble" pseudonodeAction and rezeroAction are queued up consecutively, so agreement's call to time.Now() before calling AssembleBlock, and then rezeroAction's call to time.Now() in Clock.Zero() are roughly the same moment. In that scenario (new round, period 0), having transactionPool pick a deadline on its own is roughly equivalent to having agreement do it, and agreement doesn't have any more information how soon a block is needed (when the next vote is coming) than transactionPool does.
In the scenario where it's not period 0, however, and we are using different values of AgreementFilterTimeoutPeriod0 and AgreementFilterTimeout, you could imagine a scenario where agreement might want to tell the pool it has a little more time to put a block together, perhaps to relieve whatever resource issue was causing difficulty in period 0. If we ever do that, we could provide a hint to the pool using either a deadline or some other argument later.
Yes, I agree with that. The agreement could pass a hint that would adjust the timing for the assembly. |
This PR is doing the following: 1. Moves the proposal deadline computation outside of the agreement package and onto the node package. The agreement wasn't doing anything with the deadline anyway. 2. Make the proposal deadline be configured using a configuration parameter rather then a global hard-coded value in the config package. Existing unit test provides sufficient coverage for this change.
Summary
This PR is doing the following:
Test Plan
Existing unit test provides sufficient coverage for this change.