Digest item must match that calculated #4808
Comments
mustermeiszer
added
I10-unconfirmed
What kind of transaction? Can you please link the code? |
|
We think it is some recursion issue, but I would have thought that this would break the node differently... ^^ |
Can you be more specific? Looking at your code, you don't deposit any digest item anywhere? Ahh, but you are using |
That is correct. We are using that. The weird thing is, that it fails, even when no evm transactions are present... |
Not really. My current approach is to comment out certain code-paths, restart the chain, submit and see if it hangs. |
|
Hmm, really weird. Looking over the code, I don't really get what is going on. It looks good. Especially weird that this is triggered by a transaction. If you comment out this line it works? |
Yes. It is also just happening on the relay-chain. The parachain happily produces the block without problems. |
The block author is not re-running its own block. Do other parachain nodes are able to import the block? |
|
Will they try without the relay-chain approving it? Haven't checked yet. Can try in the dev environments. Any logs to log out for? I boiled it down to this code-path. Works without it, fails with it. It is rather a portion that is running there. |
|
So if you comment out the
With Aura yes, the other nodes should import it. Just check if the other nodes manage to import the block. How can I reproduce this? Can you tell me exactly what to launch etc? Then I could also look at it. |
No, just the |
Give me 5 minutes I will adapt the issue for reproduction. Need a new branch as our launch script is out to date. |
|
@bkchr updated. The above will build our node locally. I then simply comment out certain lines and re-do the procedure. We have integration test for that code-path, so it is really weird. |
I have to correct myself. The |
|
In the non-local testnetworks the behaviour is a bit different.
At least this is my current understanding. Here are the log files. Both as csv and as json. The CSVs side by side can be seen here dev-centrifuge-collator.csv |
|
@mustermeiszer just to keep you updated. I could reproduce this locally with your instructions. I already found out that it is related to the frontier digest. Looks like the state root is different. I'm continuing to find out on what is going on. |
|
Thanks for the update!! Let me know if you need anything else. |
|
centrifuge/centrifuge-chain#1881 the fix for your issue. Underlying issue pub const fn size_of_feed<T: Config>() -> u32 {
sp_std::mem::size_of::<(T::OracleKey, T::OracleValue, MomentOf<T>)>() as u32
}The function is using
The problem with |
Does that mean, that without |
No. Then it would have failed at comparing the |
Is there an existing issue?
Experiencing problems? Have you tried our Stack Exchange first?
Description of bug
Testnet chains are halting and not producing any blocks anymore.
We recently upgrade the development environments to
release-polkadot-v1.7.2. Asyncronous backing is NOT activated.At first the chains were producing blocks just fine. But after submitting a certain transaction the block production stopped.
Relevant Logs
Versions
Relay-chain:
docker:parity/polkadot:v1.7.2Parachain:
polkadot-sdk:releases-polkadot-v1.7.2Possibly Related Issues
Possibly related to:
Steps to reproduce
Needs: Docker, rust-toolchain
git clone git@github.com:centrifuge/centrifuge-chain.gitgit checkout fix/release-0.11.0/v1./scripts/init.sh start-relay-chain./scripts/init.sh start-parachain purge./scripts/init.sh onboard-parachainThe above will start 2 relay-chain nodes and one parachain node. The parachain node is afterwards automatically onboarded.
In order to test the diggest issue you must:
0x6f00020000000000000000000000000000000000000000000000000000000000000000https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A11936#/explorerDigest MismatcherrorTo close down the setup
./scripts/init.sh stop-relay-chainThe text was updated successfully, but these errors were encountered: