Conversation
|
Ran it 25 times locally and passed each time |
| Pallet::<T>::initialize_para_now(&mut parachains, *id, genesis_args); | ||
| T::AssignCoretime::assign_coretime(*id) | ||
| .expect("Assigning coretime works at genesis; qed"); | ||
| if genesis_args.para_kind == ParaKind::Parachain { |
There was a problem hiding this comment.
I don't get this. What does with_parachain from zombienet-sdk do so that we enter in this if?
(I looked at the linked PR and still don't get it).
There was a problem hiding this comment.
By default zombienet-sdk adds parachains to the genesis state (which end up calling this code that I modified). Here is what zombienet ends up doing: https://github.com/paritytech/zombienet-sdk/blob/722993c5665efa0dd74e190729fba95abc2c0b71/crates/orchestrator/src/generators/chain_spec.rs#L670.
Whether we add the para to genesis state is determined by the RegistrationStrategy.
If we set onboard_as_parachain(false) (which I do here), the para_kind will end up being Parathread. And I don't want to have any core assigned if it's a parathread.
There was a problem hiding this comment.
Hi @alindima, could be use the RegistrationStrategy::Manual here? With this variant zombienet doesn't register the parachain, only generate the spec/artifacts and spawn the collator. Then you can register the para and assign the core from the test itself.
wdyt?
There was a problem hiding this comment.
That's what this test used to do, but it's more tedious and it takes one extra session before the parachain starts producing blocks
Rewrite it with zombienet-sdk, while simplyfing it. The main source of flakyness was timing, because this test was manually registering parachains, so we had to wait for 2 sessions. Waiting for session change with zndsl zombienet was a hassle, whereas with zombienet-sdk is much easier. Moreover, I needed to replicate the logic change from: #6554 to the genesis parachain registration, so that we don't automatically get an extra assigned core when registering a parachain (unless we want one)
5 participants
Rewrite it with zombienet-sdk, while simplyfing it.
The main source of flakyness was timing, because this test was manually registering parachains, so we had to wait for 2 sessions. Waiting for session change with zndsl zombienet was a hassle, whereas with zombienet-sdk is much easier.
Moreover, I needed to replicate the logic change from: #6554 to the genesis parachain registration, so that we don't automatically get an extra assigned core when registering a parachain (unless we want one)