-
Notifications
You must be signed in to change notification settings - Fork 303
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
Reduce wait period to avoid flakiness #8701
Changes from 3 commits
16df650
ed738bb
3a45e4c
c7e35b2
18f7e5f
43b69f0
c54beae
3bb22a3
778e65c
5d88720
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -54,7 +54,7 @@ public class MultiPeersStandAloneVcBlocksAcceptanceTest | |
|
||
firstTekuNode.start(); | ||
|
||
firstTekuNode.waitForEpochAtOrAbove(2); | ||
firstTekuNode.waitForEpochAtOrAbove(1); | ||
|
||
final int slashedValidatorIndex = 34; | ||
final BLSKeyPair slashedValidatorKeyPair = getBlsKeyPair(slashedValidatorIndex); | ||
|
@@ -74,7 +74,6 @@ public class MultiPeersStandAloneVcBlocksAcceptanceTest | |
.withGenesisTime(genesisTime) | ||
.withNetwork(network) | ||
.withRealNetwork() | ||
.withRealNetwork() | ||
.withAltairEpoch(altairEpoch) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. is removal of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. think so, although this was added by Paul's commit, we never actually reached the epoch where Altair was set. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yes it was pointless to have altair at epoch 100 when we're finishing in a few epochs... |
||
.withPeers(firstTekuNode) | ||
.build()); | ||
|
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 we're changing this anyway, i'd change this back to 2, and i'd change the genesis wait time to 60 seconds to let both nodes be online close to genesis...
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.
but i'd also be starting node 2 prior to waiting for epoch 2 i think...
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.
This wouldn't work because we would have to wait until epoch 2 to start the second node in the current logic. This would only drag the test length to a longer period of waiting. What we could do is possibly change the slashing to be in a block for the epoch 4 or 5.
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.
the BN will come up slow, so if the second BN starts before genesis and BOTH BN wait for the 2 epochs, then the second VC starts, by then the world order is a lot less ugly i think you'll find.
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.
I still don't think we should increase the lenght of genesis from 10 to 60 and make this longer than it needs to be, test usually succeeds in 50 secs. So making it longer for no reason doesn't sound a better solution. I'm ok with starting beacon2 earlier.