Fix panic in pending_runtime_api with Aura consensus env (#814)#114
Conversation
Before we were just assuming the header could be unwrapped (wrong) and now handle that error specifically. Runtime api access error message still the same. |
|
Thanks for explaining! As far as I understand
We handle header not being unwrapped by returning the client error
Now I think the runtime API access error is not emitted if the header cannot be unwrapped |
| }); | ||
|
|
||
| step("balance to be updated after transfer", async function () { | ||
| await createAndFinalizeBlock(context.web3); |
There was a problem hiding this comment.
This should go after the timeout line.
Also why do we need to create a block for this ?
There was a problem hiding this comment.
This cherry-picked solution from upstream uses parent hash for building the pending runtime api and, in the case of tests like this one, parent hash of genesis is not a valid block to initialize. Thus the need of creating one.
Tbh I don't like it and I can propose a better way of doing it upstream, which will not require modifying the tests like that.
|
So this PR applies polkadot-evm#842 to our frontier fork I'm still not sure what this has to do with pallet-randomness::on_initialize being introduced in 1802... |
Not really, or not only. This PR avoids the unwrap thing, but also builds the pending block over parent instead of best. And that's the main issue:
|
|
interesting, when is best != parent_hash? is it only when a node is syncing? |
Always. |
Rel MOON-1909