advance parachain properly in XCM-emulator for tests #3023
Conversation
| @@ -622,14 +626,16 @@ macro_rules! decl_test_parachains { | |||
| let block_number = <Self as Chain>::System::block_number(); | |||
| let mut relay_block_number = <Self as NetworkComponent>::Network::relay_block_number(); | |||
|
|
|||
| let _ = <Self as Parachain>::ParachainSystem::set_validation_data( | |||
There was a problem hiding this comment.
Calling set_validation_data here is definitely illegal so had to be removed. Tests possibly depended on it, but it lead to an impossible sequence of calls.
There was a problem hiding this comment.
elaborating a bit more. init() is called within execute_block the first time it's run.
set_validation_data needs to be followed by a System::finalize call.
It might be more correct as
- initialize
- set_validation_data
- finalize
- initialize
but that is basically just running a full block, which shouldn't be necessary during the initialization step.
joepetrowski
added
the
A3-in_progress
|
related to #2703 |
|
The CI pipeline was cancelled due to failure one of the required jobs. |
|
btw, one of the reasons these tests are so flaky is because the The side-effecting nature of the code here would likely make it near-impossible to write tests which didn't depend on highly specific implementation details and control flow of the test runner, as well as the ordering of calls to Strongly recommend a refactoring here. Executing a block on a parachain should cause messages to be processed only to itself. This may require tests to be rewritten to deliberately execute empty blocks on a receiving parachain in order to observe the events - this is OK and what happens in the real world. |
This is cherry-picked from #2300 - we needed to treat the parachain as an actual chain for the unincluded segment logic introduced in #2948 .
This PR has test failures which need to be fixed by the system parachains folks