app can't send extrinsic and waits forever - Githubissues

encointer / encointer-wallet-flutter

Encointer mobile wallet flutter implementation

https://encointer.org

Apache License 2.0

21 stars 15 forks source link

app can't send extrinsic and waits forever #1659

Closed brenzi closed 6 months ago

brenzi commented 6 months ago

second time this happened to me with 1.13.2 after the app was active for a long time

send Leu
wait on confirmation screen forever

there are no pending extrinsics, so the app most likely didn't even attempt to send

kill app and retry fixes the issue

brenzi commented 6 months ago

had the same behaviour after only a couple of minutes now:

change account and try to send ceremonies.register right away. hangs forever and no pending xt

clangenb commented 6 months ago

I had this once while testing too. The extrinsic reaches the node apparently, because we get an extrinsic update as a return value, where it says that the txStatus update is 'ExtrinsicUpdate: invalid'. I don't know yet why this happens yet, but a simple retry succeeded.

clangenb commented 6 months ago

Interestingely, I also got this error the rust-cli against a rococo-local setup (https://github.com/encointer/encointer-parachain/commit/5c320a1bbdff256956b0e148d5ad7f5f32282833):

./bootstrap_demo_community.py --client ../target/release/encointer-client-notee                      ok | 19:13:04
IPFS environment not set up for using gateway
connecting to remote chain:  ws://127.0.0.1
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: UnexpectedTxStatus(Invalid)', client/src/utils.rs:68:78
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

So maybe the error has nothing to do with our dart api, and we just need to make sure to catch it on the dart side and offer, or do automatically, a retry.

clangenb commented 6 months ago

With txpool trace logs, it seems that it happens when a transaction is resubmitted from retracted block, but I feel I have seen more invalid transactions than this log occurs:

2024-03-19 19:42:48.023 DEBUG tokio-runtime-worker txpool: [Parachain] [0xd9b0e7fc0b71dc3e607accfa09c8da93971044bd8dc9691af4bf41d4f7af186e]: Resubmitting from retracted block 0x2a6d3538913d4f5c31cd4c3977c42de1593b4cb563533029c0ada2be773e8ba3
2024-03-19 19:42:48.023 DEBUG tokio-runtime-worker txpool: [Parachain] Sent 1 transactions to revalidation queue
2024-03-19 19:42:48.024 DEBUG tokio-runtime-worker txpool: [Parachain] Updated revalidation queue at 0xa9eab83603d7acd3929d3fc9dd20cb1b3dfaeceec03030e42b9c0c8202e7a099. Transactions: {0x09537e21724e4d78b28410a19ea4cb7e617fd072f0f6bfa5cb913a78dd5b8fca: 0xa9eab83603d7acd3929d3fc9dd20cb1b3dfaeceec03030e42b9c0c8202e7a099}
2024-03-19 19:42:48.026 TRACE tokio-runtime-worker txpool: [Parachain] Transaction pool already processed block  #39
2024-03-19 19:42:48.026 DEBUG tokio-runtime-worker txpool: [Parachain] [0x09537e21724e4d78b28410a19ea4cb7e617fd072f0f6bfa5cb913a78dd5b8fca] Reported as invalid. Will skip sub-chains while iterating.
2024-03-19 19:42:48.026 DEBUG tokio-runtime-worker txpool: [Parachain] Removing invalid transactions: [0x09537e21724e4d78b28410a19ea4cb7e617fd072f0f6bfa5cb913a78dd5b8fca]
2024-03-19 19:42:48.026 TRACE tokio-runtime-worker txpool: [Parachain] [0x09537e21724e4d78b28410a19ea4cb7e617fd072f0f6bfa5cb913a78dd5b8fca] Removed as part of the subtree.
2024-03-19 19:42:48.026 DEBUG tokio-runtime-worker txpool: [Parachain] Removed invalid transactions: [Transaction { hash: 0x09537e21724e4d78b28410a19ea4cb7e617fd072f0f6bfa5cb913a78dd5b8fca, priority: 8, valid_till: 102, bytes: 195, propagate: true, source: TransactionSource::External, requires: [], provides: [90b5ab205c6974c9ea841be688864633dc9ca8a357843eeacf2314649965fe2203000000], data: 840090b5ab205c6974c9ea841be688864633dc9ca8a357843eeacf2314649965fe22013eead0752247203b8d39e1e2b640927325dbf39d0a9834090d36f5aaff16591e85433466af056d03f77fe1511aa8d599df7a6ebb61418bd873f42643a78cf78a75020c000173716d3176f08c911c3d0373716d3176f08c911c0300000008d43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d8eaf04151687736326c9fea17e25fc5287613693c912909cb226aa4794f26a48}]

clangenb commented 6 months ago

I found this issue that might be related https://github.com/paritytech/polkadot-sdk/pull/3079 and have the following thoughts:

Either the behavior implemented in that PR is not quite correct, and submitting a transaction from a retracted block doesn't work.
The PR description made me wonder if we send a tx based on the best block (instead of the latest finalised block) and if that best block is no longer in the canonical chain, we might get this error.

I actually think it is the latter because the above log, doesn't always occur when I get an invalid transaction, hmm.

clangenb commented 6 months ago

Ok, I have to revert my statement, I am now quite positive that the above log always occurs when we have a retracted block. However, I wonder if my second bullet point is related to the first one. If we construct the transaction based on finalized block data instead of best block, then the validation of the resubmitted transaction should work. Aka, this just means that we need to supply the latest finalized blockhash/-number instead of the best blockhash/-number. I will try that.