-
Notifications
You must be signed in to change notification settings - Fork 214
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
[Merged by Bors] - Extend proposal builder to allow the use of a fallback active set. #5378
Conversation
9294372
to
049d58f
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## develop #5378 +/- ##
=========================================
- Coverage 77.3% 77.3% -0.1%
=========================================
Files 258 258
Lines 30526 30590 +64
=========================================
+ Hits 23599 23648 +49
- Misses 5429 5444 +15
Partials 1498 1498 ☔ View full report in Codecov by Sentry. |
@@ -368,6 +373,20 @@ func (pb *ProposalBuilder) decideMeshHash(ctx context.Context, current types.Lay | |||
return mesh | |||
} | |||
|
|||
func (pb *ProposalBuilder) UpdateActiveSet(epoch types.EpochID, activeSet []types.ATXID) { |
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.
what about also providing weight as a part of fallback data?
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.
We could, I wanted to avoid that because for this we have to change the schema of the json thats inside the bootstrap file; to change it in a backwards compatible way the weight would then be optional.
yes we should persist it on every node, otherwise non-smeshing nodes will ask it over the p2p network
it is better to drop it from this pr, it is covered in my change. what about sharing weight as well? it would make this hack more robust |
Will add that.
I saw 🙂 for the test build I removed my code and used the code from your PR.
we could; I wasn't sure about it because it will force all nodes to update then (even for beacon). |
do you mean that if we will add one new field, old versions will reject data with that field? |
I didn't try, just adding the field probably works. We can also add it to the schema if we don't make it a required field (to not break backwards compatibility). At the moment the only required fields are |
616c2b7
to
4201550
Compare
a286765
to
44d50ce
Compare
bors merge |
…5378) ## Motivation related to #5366 Allow to set a fallback active set to be used by the proposal builder via the same mechanism as we use for the fallback beacon. ## Changes - some minor fixes in `bootstrap` cmd code - extend `ProposalBuilder` to be able to set a specific active set for an epoch - extend node routine listening for updates to fallback beacon / activeset to propagate a fallback to the `ProposalBuilder` ## Test Plan - added test case to `ProposalBuilder` to verify use of fallback active set if available - manual testing on `testnet-10` ## TODO <!-- This section should be removed when all items are complete --> - [x] Explain motivation or link existing issue(s) - [x] Test changes and document test plan - [x] Update documentation as needed - [x] Update [changelog](../CHANGELOG.md) as needed
Build failed:
|
bors merge |
…5378) ## Motivation related to #5366 Allow to set a fallback active set to be used by the proposal builder via the same mechanism as we use for the fallback beacon. ## Changes - some minor fixes in `bootstrap` cmd code - extend `ProposalBuilder` to be able to set a specific active set for an epoch - extend node routine listening for updates to fallback beacon / activeset to propagate a fallback to the `ProposalBuilder` ## Test Plan - added test case to `ProposalBuilder` to verify use of fallback active set if available - manual testing on `testnet-10` ## TODO <!-- This section should be removed when all items are complete --> - [x] Explain motivation or link existing issue(s) - [x] Test changes and document test plan - [x] Update documentation as needed - [x] Update [changelog](../CHANGELOG.md) as needed
Pull request successfully merged into develop. Build succeeded:
|
…5378) ## Motivation related to #5366 Allow to set a fallback active set to be used by the proposal builder via the same mechanism as we use for the fallback beacon. ## Changes - some minor fixes in `bootstrap` cmd code - extend `ProposalBuilder` to be able to set a specific active set for an epoch - extend node routine listening for updates to fallback beacon / activeset to propagate a fallback to the `ProposalBuilder` ## Test Plan - added test case to `ProposalBuilder` to verify use of fallback active set if available - manual testing on `testnet-10` ## TODO <!-- This section should be removed when all items are complete --> - [x] Explain motivation or link existing issue(s) - [x] Test changes and document test plan - [x] Update documentation as needed - [x] Update [changelog](../CHANGELOG.md) as needed
Motivation
related to #5366
Allow to set a fallback active set to be used by the proposal builder via the same mechanism as we use for the fallback beacon.
Changes
bootstrap
cmd codeProposalBuilder
to be able to set a specific active set for an epochProposalBuilder
Test Plan
ProposalBuilder
to verify use of fallback active set if availabletestnet-10
TODO