fix para-tests

[nbaztec]

What does it do?

fixes para-tests to use rpc endpoint to detect RT upgrade, similar to the subscription.

What important points reviewers should know?

Is there something left for follow-up PRs?

What alternative implementations were considered?

Are there relevant PRs or issues in other repositories (Substrate, Polkadot, Frontier, Cumulus)?

What value does it bring to the blockchain users?

[crystalin]

I think this is fixed already by #1862 (fix for waitMigration)

[nbaztec]

I think this is fixed already by #1862 (fix for waitMigration)

If that's the intended assertion for the test, then we can close this PR. I was under the assumption that we wanted to fix the wait behavior so it is not out-of-sync with rpc & storage. Do we know why we need to wait 1 block after the rpc signals that the RT upgrade is done?

[crystalin]

I'm not sure I understand your question, but the runtime upgrade always happens in 2 steps:

• The new runtime is applied
• The following block execute the runtime migration

The waitMigration allows to wait until the block doing the runtime migration is executed

[crystalin]

We can add the RPC check in the test, but I want to make sure we keep the on-chain test as it is more important to have this one correct

[nbaztec]

I'm not sure I understand your question, but the runtime upgrade always happens in 2 steps:

• The new runtime is applied
• The following block execute the runtime migration

Does this mean that:

• RPC endpoints already report the new version when runtime is applied (as shown by the test). We use api.rpc.subscribeNewRuntime which returns the new version 1 block before the storage is updated.
• And by extension, the storage is only updated when the runtime is executed
  ?

[crystalin]

Does this mean that:

• RPC endpoints already report the new version when runtime is applied (as shown by the test). We use api.rpc.subscribeNewRuntime which returns the new version 1 block before the storage is updated.

I don't know when it reports it, but yes it is likely to be before the on-chain.
The reason is that the node import the block right when it is produced. But the on-chain is considered best, when the block is included in the relay chain (so 12s later usually).

• And by extension, the storage is only updated when the runtime is executed
  ?

The storage gets updated in the block doing the migration (1 after the runtime is applied)
Ex: Moonbeam 1803 (applied at 2073477, and migrated at 2073478

[nbaztec]

Cool thanks, think it's fine to close this one then, if the behavior is well understood.