So it is:
1) if nonce is specified by the caller AND it is not -1, then it is used
2) if nonce is specified by the caller AND it is -1, then it is read from the node using api.rpc.system.accountNextIndex(_), which returns next nonce, taking into account all extrinsics from the pool
3) if nonce is not specified by the caller, then it is read from the node using api.derive.balances.account(_).accountNonce, which returns next nonce, NOT taking into account all extrinsics from the pool
The polkadot-js-api cli package doesn't pass the nonce, hence it always uses the 3rd option, which effectively limits number of transactions to one per block (because all following submissions will fail because the same nonce is used). We are using this package (thank you @jacogr ) in bridges tests and we want to submit more than 1 tx per block, hence this PR
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
The logic which determines nonce that is used when signing transaction is here:
So it is: 1) if
nonce
is specified by the caller AND it is not-1
, then it is used 2) ifnonce
is specified by the caller AND it is-1
, then it is read from the node usingapi.rpc.system.accountNextIndex(_)
, which returns next nonce, taking into account all extrinsics from the pool 3) ifnonce
is not specified by the caller, then it is read from the node usingapi.derive.balances.account(_).accountNonce
, which returns next nonce, NOT taking into account all extrinsics from the poolThe
polkadot-js-api
cli package doesn't pass thenonce
, hence it always uses the 3rd option, which effectively limits number of transactions to one per block (because all following submissions will fail because the same nonce is used). We are using this package (thank you @jacogr ) in bridges tests and we want to submit more than 1 tx per block, hence this PR