selsta: yes I have my own set of tests in my libraries and for haveno

jeffro256: it's difficult to recreate in a basic test, I haven't succeeded so far. but best guess is that 2 transactions are relayed at the same time with deposits to the multisig wallet, and maybe the participants observe the txs in different orders

one curious thing though is that signing a multisig tx fails with "stale data" if you first call export_multisig_info on the signing wallet. I'm surprised merely exporting causes signing to become stale

opened an issue for scan_tx failing in the release branch if the wallet is already synced, with the error message "Expected block not returned by daemon": monero-project/monero #8951

on it

thanks

not seeing what could be causing this yet, do you have tests I can check out woodser?

just this which calls scan_tx on monero-wallet-rpc with a few of its tx ids: github.com/monero-ecosystem/monero-…WalletCommon.java#L4520C21-L4520C21

the wallet is synced when scan_tx is called which seems to be make the difference. I observe the same error with a native binding to wallet2 if the wallet is synced, but it works if the wallet isn't synced

hmm, the only way to hit that error should be if there are 2+ txs to scan/rescan at the same height, where at least 2 of those txs aren't pool/coinbase txs

which looks to be the case in your test

but it should still fetch those txs' block(s) from the daemon thanks to this: github.com/monero-project/monero/bl…58d4a7/src/wallet/wallet2.cpp#L1681

going to set up a dev env to repro your tests and dig from there

they may all be coinbase txs

yes they're all coinbase txs

does that wallet only have coinbase txs in it?