-
Notifications
You must be signed in to change notification settings - Fork 710
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
Bump a timeout in zombienet coretime smoke test #6268
Conversation
@@ -9,7 +9,7 @@ coretime-collator: is up | |||
alice: js-script ./0004-configure-relay.js with "" return is 0 within 600 secs | |||
|
|||
# Coretime chain should be producing blocks when the extrinsic is sent | |||
alice: parachain 1005 block height is at least 10 within 120 seconds | |||
alice: parachain 1005 block height is at least 10 within 180 seconds |
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.
is this so high because we need to wait two sessions?
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.
Afaik it's one session (10 blocks which is around a minute). On top of this we need some time to get to 10 blocks worst case (for my local run it was around 7 block) which is another 40 secs. Or 100 secs total.
Initially I thought 120secs should be enough to finish this but I noticed a job failed at this step so I decide to put one more minute to be on the safe side.
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.
hmm but with 180 seconds minus the 60 for the session change, this would basically mean 12-second blocks. isn't it a bit too much? I'm afraid of adding timeouts that are too large which would then mask other issues.
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.
maybe let's leave 8 seconds for each block (which is what we do in other tests AFAIK)
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.
Just to make sure we are on the same page. As soon as ./0004-configure-relay.js
executes the coretime chain stalls. It unstalls after one complete session.
So we have:
- a few blocks to let the old session finish (let's say 5?)
- 10 blocks for a new session
- 7 blocks to reach the threshold after the change kicks in
(5+10+7)*8=176 secs
for a timeout which by pure luck is around my estimate.
Maybe it's safe to decrease the threshold to 6 with a timeout of 150 secs?
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.
So we have:
a few blocks to let the old session finish (let's say 5?)
10 blocks for a new session
Ok so indeed two sessions need to pass. It's ok then
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.
Sorry, I've misunderstood you initially. I thought you mean two full sessions.
/cmd prdoc --bump none --audience node_dev |
Command "prdoc --bump none --audience node_dev" has failed ❌! See logs here |
/cmd prdoc --bump no_change --audience node_dev |
Signed-off-by: Oliver Tale-Yazdi <[email protected]>
polkadot/zombienet_tests/smoke/0004-coretime-smoke-test.zndsl still timeouts on CI from time to time. Bumping the timeout a bit more.
Related to #6226