Conversation
7efc53d to
598e7d8
Compare
c64f36f to
e51081d
Compare
0cde9df to
6c81611
Compare
6c81611 to
bf1aee8
Compare
clangenb
left a comment
There was a problem hiding this comment.
Looks actually good to me, I don't know how the CI error can occur yet.
|
I see these errors in the log, seem to be new: see M6 offchain test |
|
started testing manually: locally with SW mode and skip-ra: https://hackmd.io/@brenzi5/HJ8Y2Sr5n
|
|
seems like our integritee-node is notcompatible with rpc behavior of api-client polkadot-0.9.42-tag-1.10 therefore, integritee-service thinks that extrinsics fail when they don't and block hashes are wrong (wrong hash is fixed with next commit) not sure if this could help: |
| enclave_count_of_previous_block, | ||
| register_enclave_xt_header.parent_hash() | ||
| ); | ||
| Ok(enclave_count_of_previous_block == 0) |
There was a problem hiding this comment.
I really don't get the logic of this. It's here for a while already: why so complicated?
why check that enclave count was zero in the previous block when we can check that it is 1 in the current block?
I didn't touch it beyond logging because we'll kick that out anyway and replace it with per-shard ShardStatus logic
|
I reproduced sending a transfer extrinsic with an api-client example and the successful jsnrpc log looks like this: I will now gather the same type of log for the failing case here |
|
ok. our issue was scs/substrate-api-client#624 |
|
back to square one:
|
| enclave_count_of_previous_block, | ||
| register_enclave_xt_header.parent_hash() | ||
| ); | ||
| Ok(enclave_count_of_previous_block == 0) |
|
I will merge it, as the instability has been noted before and does not have to do with this PR, see #1403 |
Required PRs to be merged / issues to be solved first:
Closes #1303.
Closes #1379.