got Error ExtrinsicNotFound although extrinsic succeeded (for extrinsic with zero-padding at the end) #624
Comments
|
maybe also the cause for #621 ? |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
Found the problem of the wrong hash calculation. We encoded the extrinsic twice - a PR fixing this is incoming. What's left to investigate: Why does |
|
@brenzi or @clangenb I am not able to reproduce this issue. I have tested it with our most recent version and the kitchensink_runtime, and it works so far (https://github.com/scs/substrate-api-client/blob/bh/test-long-xt/examples/examples/test_long_xt.rs) When testing with a really long xt and the integritee-node polkadot-v0.9.42, I get the error Could you provide some information on how I can reproduce this issue? |
|
what I can say is we used the polkadot-v0.9.42-tag-v0.10.0 branch |
|
Can this be the reason for the failure? |
|
That would be surprising. Substrate handles it the same way: And I just tested if the difference between the two functions matters, but the output is the same. (with the following test:) #[cfg(test)]
mod tests {
use super::*;
use sp_core::hashing::blake2_256;
#[test]
fn encode_decode_roundtrip_works() {
let bytes = "afaefafe1204udanfai9lfadmlk9aömlsa".as_bytes();
assert_eq!(&blake2_256(bytes)[..], &BlakeTwo256::hash(bytes)[..]);
}
}But definitely not something to ignore, I suppose - there might be a small difference somewhere (e.g. Susbtrate using a different struct, the api-client not using it the same as Substrate..) |
|
No, my question was rather that in one case we return the payload directly and in the other case only hash of it: |
|
Somehow, it seems a little strange to me: Polkadot.js can not decode the long version of the extrinsic in the logs you sent @brenzi , but the short version, reported in the block (
tested on integritee rococo (https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frococo.api.integritee.network#/extrinsics/decode) |
|
I have added some unit tests that check the extrinsic encoding and hashing thereof (by comparing them to the substrate implementation). That does seem to work, so I don't think that's the problem (see #636 ) The main question for me now is: Why is the extrinsic sent longer than the one reported in the block? I don't think Substrate truncates extrinsic, as this would result in information loss. |
|
Another thought: Could the subscription be from the wrong extrinsic? According to #620 (comment) the reported block hash is wrong. That would certainly mess up everything. Would need some investigation in our older rpc-clients (ws-client and tungstenite-client) |
|
Still getting this error on: https://github.com/scs/substrate-api-client/tree/polkadot-v0.9.42-tag-v0.14.0 |
|
I did some thorough investigation and did not find anything. But I can rule out the following:
In the api client itself, there is no truncating happening of the extrinsic and the decoding thereof. It can handle xt longer than 256 bytes without any problems. My only leads left:
|
|
Removing the bug label for now because I'm almost certain this is not an api-client issue. Still leaving the ticket open though because the api-client should be helpful in debugging this issue, but further information from your side is needed. |
|
The error has finally been fixed. It came from the Integritee side, and Litentry has fixed it in integritee-network/worker#1505. 🥳 Thanks a lot for your investigation! |
brenzi
changed the title
If an extrinsic is very long, the
submit_and_watch_extrinsic_until_successfails:it seems the block header truncates extrinsics if they are too long. Therefore, the logic for searching extrinsics fails.
The text was updated successfully, but these errors were encountered: