Sending TX's multiple times in quick succession from the same sender account, fails

Hi. I thought that the “broadcast-mode” option for the CLI’s “tx” interface would ensure that I could “rapid-fire” transactions through from the same account, but I keep getting errors.

Here is the kind of command I am running:

echo mypassword | foocli tx bank send foo13m5p9y4fsp45utx98jxhjj9z8ul45v4a0mdz7j foo13m5p9y4fsp45utx98jxhjj9z8ul45v4a0mdz7j 24008abc --gas-prices 0.01abc --from validator --yes --broadcast-mode sync

The first such TX succeeds but anything sent quickly after this fails with the following subset of the JSON response:

‘raw_log’: ‘{“codespace”:“sdk”,“code”:4,“message”:“signature verification ’
'failed; verify correct account sequence and chain-id”}’,

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?

Please advise.

1 Like

So as an update for others.

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:

Hope this help :slight_smile:

3 Likes