IF: Disaster_recovery scenario 2 test #72
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Observed test failure: |
greg7mdp
reviewed
Apr 29, 2024
greg7mdp
approved these changes
Apr 30, 2024
linh2931
reviewed
Apr 30, 2024
|
|
||
| ############################################################### | ||
| # disaster_recovery - Scenario 2 | ||
| # |
There was a problem hiding this comment.
I like the detailed description here. It will be even better for each of scenarios to have one sentence describing what the purpose of the test.
I think our new tests should follow this test's pattern.
linh2931
reviewed
Apr 30, 2024
linh2931
approved these changes
Apr 30, 2024
greg7mdp
approved these changes
Apr 30, 2024
linh2931
approved these changes
May 1, 2024
|
Note:start |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Disaster Recovery Scenario 2
Integration test with 5 nodes (A, B, C, D, and P). Nodes A, B, C, and D each have one finalizer but no proposers. Node P has a proposer but no finalizers. The finalizer policy consists of the four finalizers with a threshold of 3. The proposer policy involves just the single proposer P.
A, B, C, and D can be connected to each other however we like as long as blocks sent to ndoe A can traverse to the other nodes B, C, and D. However, node P should only be connected to node A.
At some point after IF transition has completed and LIB is advancing, block production on node P should be paused. Enough time should be given to allow and in-flight votes on the latest produced blocks to be delivered to node P. Then, the connection between node P and node A should be severed, and then block production on node P resumed. The LIB on node P should advance to but then stall at block N. Then shortly after that, node P should be cleanly shut down.
Verify that the LIB on A, B, C, and D has stalled and is less than block N. Then, nodes A, B, C, and D can all be cleanly shut down.
Then, reversible blocks from all nodes should be removed. All nodes are restarted from an earlier snapshot (prior to block N).
P is restarted and replays up to block N after restarting from snapshot. Blocks up to and including block N are sent to the other nodes A, B, C, and D after they are also started up again.
Verify that LIB advances and that A, B, C, and D are eventually voting strong on new blocks.