-
Notifications
You must be signed in to change notification settings - Fork 332
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
fix(registry): disable replacement of nodes that are active in subnets #3935
Conversation
### Summary - Disabled tests related to node replacement in subnet. ### Details - Marked `should_add_node_and_replace_existing_node_in_subnet` as ignored in `do_add_node.rs` pending Consensus team support. - Marked `should_replace_node_in_subnet_and_update_allowance` as ignored in `do_remove_node_directly.rs` pending Consensus team support. ### Additional Changes - Introduced `replacements_of_nodes_in_subnets_enabled` flag set to `false` in `do_remove_node_directly.rs` to conditionally control node replacement logic.
7d4eccf
to
8c1e08c
Compare
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.
If this pull request affects the behavior of any canister owned by
the Governance team, remember to update the corresponding
unreleased_changes.md file(s).
To acknowldge this reminder (and unblock the PR), dismiss this
code review by going to the bottom of the pull request page, and
supply one of the following reasons:
-
Done.
-
No canister behavior changes.
#3935) Direct node replacements of nodes that are active in a subnet may result in unexpected behavior and potential problems in the current Consensus code. So to be on the safe side we need to disable the functionality on the Registry side until the rest of the core protocol can handle it safely. --------- Co-authored-by: CI Automation <[email protected]> Co-authored-by: Arshavir Ter-Gabrielyan <[email protected]>
Direct node replacements of nodes that are active in a subnet may result in unexpected behavior and potential problems in the current Consensus code.
So to be on the safe side we need to disable the functionality on the Registry side until the rest of the core protocol can handle it safely.