rewrite some flaky zombienet polkadot tests to zombienet-sdk #6757
Conversation
alindima
added
R0-silent
|
Hi @alindima, I think this is failing because we need to hide the |
alindima
changed the title
polkadot/zombienet-sdk-tests/tests/elastic_scaling/basic_3cores.rs
Outdated
Show resolved
Hide resolved
polkadot/zombienet-sdk-tests/tests/elastic_scaling/doesnt_break_parachains.rs
Show resolved
Hide resolved
|
|
||
| // Assert the parachain finalized block height is also on par with the number of backed | ||
| // candidates. | ||
| assert_finalized_block_height(¶_node.wait_client().await?, 6..9).await?; |
There was a problem hiding this comment.
While I get that we don't want flaky tests. It is kind of concerning that we let tests pass if we do less blocks than expected. We definitely need some tests in some fashion ensuring that we are not degrading.
There was a problem hiding this comment.
While I get that we don't want flaky tests. It is kind of concerning that we let tests pass if we do less blocks than expected.
I mean, we've always done this in the CI so far. The only way of fixing this IMO is to invest more in the reliability and performance of the CI machines
…into alindima/zombienet-sdk-rewrite
|
All GitHub workflows were cancelled due to failure one of the required jobs. |
Yep, I ran them like 5-6 times each and we should be good |
…aling (#6983) On top of #6757 Fixes #6858 by bumping the `PARENT_SEARCH_DEPTH` constant to a larger value (30) and adds a zombienet-sdk test that exercises the 12-core scenario. This is a node-side limit that restricts the number of allowed pending availability candidates when choosing the parent parablock during authoring. This limit is rather redundant, as the parachain runtime already restricts the unincluded segment length to the configured value in the [FixedVelocityConsensusHook](https://github.com/paritytech/polkadot-sdk/blob/88d900afbff7ebe600dfe5e3ee9f87fe52c93d1f/cumulus/pallets/aura-ext/src/consensus_hook.rs#L35) (which ideally should be equal to this `PARENT_SEARCH_DEPTH`). For 12 cores, a value of 24 should be enough, but I bumped it to 30 to have some extra buffer. There are two other potential ways of fixing this: - remove this constant altogether, as the parachain runtime already makes those guarantees. Chose not to do this, as it can't hurt to have an extra safeguard - set this value to be equal to the uninlcuded segment size. This value however is not exposed to the node-side and would require a new runtime API, which seems overkill for a redundant check. --------- Co-authored-by: Javier Viola <[email protected]>
Will fix:
#6574
#6644
#6062