Skip to content
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

Merged
merged 3 commits into from
Oct 30, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor

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)

Copy link
Contributor Author

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?

Copy link
Contributor

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

Copy link
Contributor Author

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.


# configure broker chain
coretime-collator: js-script ./0004-configure-broker.js with "" return is 0 within 600 secs
Expand Down
10 changes: 10 additions & 0 deletions prdoc/pr_6268.prdoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
title: Bump a timeout in zombienet coretime smoke test
doc:
- audience: Node Dev
description: |-
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 https://github.com/paritytech/polkadot-sdk/issues/6226
crates:
- name: polkadot
bump: none
Loading