Parity-ethereum: Need more info on: "Transaction gas price is too low. There is another transaction with same nonce in the queue. Try increasing the gas price or incrementing the nonce."

[tayvano]

Can someone explain to us what causes this error message:

TooCheapToReplace => {
"Transaction gas price is too low. There is another transaction with same nonce in the queue. Try increasing the gas price or incrementing the nonce.".into()
},

from https://github.com/ethcore/parity/blob/e57c616f72d849310c36b3e438c09cf9858df9ac/rpc/src/v1/helpers/errors.rs

We're having a lot of reports of this error from our users on MyEtherWallet & we are trying to determine if it's a gas price issue or a nonce issue (both would be on our end). We have been having other issues with gas _limit_, specifically the estimateGas() functionality....but this error message makes it seem unrelated.

Can anyone give us any info or point us in the right direction as we attempt to troubleshoot. Thank you.

[tomusdrw]

This error happens in a scenario:

1. Transaction tx1=(sender=s, nonce=n, gas_price=g1) is insterted to the queue correctly (returns Current/Future)
2. Then you try to send another transaction tx2=(sender=s, nonce=n, gas_price=g2) where g2 <= g1

So it should happen only if nonce is set manually (cause if transaction tx1 is in the queue next nonce should be used instead).
The message also suggests that if you really want to replace tx1 with tx2 you should set g2 > g1 - in such case we accept tx2 and drop tx1 from the queue.

It would be good to get some more details about the setup, especially what method is used to determine nonce for transaction. If you are relying on a default to be set correctly by Parity then it might be a bug.

[kvhnuke]

I am having hard time reproducing the same issue but it happened to me couple of times where parity will return the same nonce without incrementing it. For example it'll return n for the first tx and while the first tx is in the pool if you request the eth_getTransactionCount it'll return n again.

[kvhnuke]

I'm starting to wonder whether parity has some sort of caching built into it to speed up the RPC calls 🤔

[tomusdrw]

We don't cache RPC calls, but we do cache latest nonce in the queue.
Depending on the setup eth_getTransactionCount is getting latest nonce from pending block (if there is one) or from transaction queue, so sometimes the results might be inconsistent.
https://github.com/ethcore/parity/blob/master/ethcore/src/miner/miner.rs#L629

Are you running with --force-sealing or mining on the same node (it would create pending block and get the nonce from there instead of the queue)?

[tomusdrw]

So it seems that eth_getTransactionCount is never checking the transaction queue, so it's not a reliable way to get a next nonce (in case a pending block is full some transactions may still await in the queue).

We are discussing the other options for you now.

[kvhnuke]

Thanks @tomusdrw, for your previous question no we are not running with --force-sealing nor mining on the same node

[tomusdrw]

Ok, so in such case eth_getTransactionCount will always return a nonce from latest block - so if you use this method to determine next available nonce users can't schedule more then one transaction (they have to wait for a previous one to be mined before submitting next).

I'll prepare a custom RPC to get next nonce reliably.

As a workaround you can either:

1. use ethcore_pendingTransactions to get all transactions from the queue and then calculate next nonce manually
2. or run with --force-sealing and high gas limit (to have all pending transactions included in pending block) - but this may increase a load of your node, since all transactions in the network will be executed twice (once for pending, once for a mined block)

[gavofyork]

Added the RPC in #2917.

[tayvano]

Thanks all!

[barakman]

@gavofyork:

I'm getting this problem with --force-sealing and --tx-gas-limit=0x1000000000.

Is it possible that I also need --reseal-on-txs=all?

I am currently using --reseal-on-txs=none.

Thanks