Local transactions rejected due to low fee that work elsewhere

[andrewheadricke]

I'm running:

• Which Parity version?: 1.11.0
• Which operating system?: Linux
• How installed?: via binaries
• Are you fully synchronized?: yes
• Which network are you connected to?: ethereum
• Did you try to restart the node?: yes

When submitting a transaction to the node, either via local wallet OR some externally signed tx it returns an error saying gas price is too low and tx queue is too long, therefore its dropped.

However my fee is always above the suggested average at ethgasstation, and when I send my tx via another provider it goes through immediately and is confirmed usually within 30-60 seconds.

There needs to be a way to forcefully allow local transactions over external ones.

[AdvancedStyle]

I'm having exact same issue after upgrading from v1.9.4 to 1.11.1:

There are too many transactions in the queue. Your transaction was dropped due to limit. Try increasing the fee.

Even if I increase the gas price to double the suggested gas price it still gives this error.

parity_localTransactions is showing rejected transactions with this error:

"error": "[0xd29a845c0f779b7e639d774e667b2253957bc312367cea481e7deaf80317644b] too cheap to enter the pool. Min score: 0x11e1a300"

This transaction has a gas price of 0x560de0700

[gituser]

I'm having same issue, getting this response over RPC:

    'code' => -32010,
    'message' => 'There are too many transactions in the queue. Your transaction was dropped due to limit. Try increasing the fee.',

also, some transactions reported as mined, but in fact they were never included in the block and thus any new outgoing transactions are stuck because the nonce should be incremented from the last mined tx.

[tomusdrw]

Are all transactions originating from the same sender? Could you please try to increase --tx-queue-per-sender parameter to see if it helps with the issue?

Default value for this is 1% of the entire pool size, so a pool of 65k can support up to 600 transactions from a single sender.

There needs to be a way to forcefully allow local transactions over external ones.

I agree. We are investigating possible solutions.

[andrewheadricke]

@tomusdrw I don't believe they are all from the same sender.. my tx queue is showing 8192 transactions, with varying senders and gas prices.

I have just set --min-gas-price to 20 gwei, that has dropped my tx queue down to a more reasonable number. Not sure if Parity will allow me to submit a local tx with a lower gas price, my gut feeling is that it will. If so, that solution will do for now.

Edit: Wow, this guy is really spamming the network https://etherscan.io/address/0xceceaa8edc0830c7cec497e33bb3a3c28dd55a32

[gituser]

@tomusdrw, in my case - most transactions are going from the same sender or to the same sender.
Also some are just stuck waiting to be mined, althrough log indicates that transaction has been mined.

But it doesn't matter, with v1.10.4 it works and with v1.9.7 it worked, why it should fail with v1.11.1 ?

I've also set --tx-queue-size to big number, I'll try your workaround, but I'm strongly believe this new parallel txqueue got a bug somewhere.

[andrewheadricke]

Can confirm setting --min-gas-price works by reducing the tx queue to a point where its not full, and then was able to submit a tx below the --min-gas-price locally and Parity accepted it and relayed it.. to which it then got mined.

[gituser]

@andrewheadricke I never submit any transactions with gasPrice below 20 Gwei. The node is only used by me so I can't see how this is relevant in my case.. I'll try though your suggestion. Thanks.

[tomusdrw]

@andrewheadricke I've submitted a fix for a local transaction policy in case the pool is full. Indeed local transactions should be accepted even if they are below configured min gas price.

@gituser Your issue seems a bit different if you are running with 65k pool size. I don't think it should ever be completely filled. Would you be able to provide logs for running with -ltxqueue=debug?