I know the chain-id is correct. So I am guessing now that the account sequence # is not being incremented. But that does not make sense either to me – isn’t that sequence # going to increment when you are in sync mode?
I was assuming here that if foocli is run in broadcast-mode’s “sync” mode, it would return AND the next time I ran foocli, it is guaranteed to have the next sequence number for that account.
I guess that’s not true. When it returns from sync mode, indeed it is safe to send another tx with that next sequence number, BUT you need to manually provide the incremented sequence number… foocli will not automatically get it (foocli only gets the sequence number reflective of the last block, not reflective of tx’s that are in the mempool).
It does mean of course, that you cannot have multiple entities sending transactions through the same account… they would have no way to now which sequence number to use.
Since cosmos-sdk v0.38 it is not possible to broadcast multiple transactions with the same account within the same block, even with an incremented account sequence.
The code responsible for this is the IncrementSequenceDecorator and its doc says:
As a result, this has the side effect that subsequent and sequential txs orginating from the same account cannot be handled correctly in a reliable way. To send sequential txs orginating from the same account, it is recommended to instead use multiple messages in a tx.
As my project really needs to create multiple transactions from the same account in the same block, we came up with a hack to force IncrementSequenceDecorator to always behave as the transaction is not a CheckTx or RecheckTX by creating forceCheckTxProxyDecorator to wrap the original IncrementSequenceDecorator.
Here is how we use it in the app.go: