Local transaction dropped

[littleskunk]

Before filing a new issue, please provide the following information.

I'm running:

• Which Parity version?: 1.11.4
• Which operating system?: Windows
• How installed?: via installer
• Are you fully synchronized?: yes
• Which network are you connected to?: ethereum
• Did you try to restart the node?: no

Your issue description goes here below. Try to include actual vs. expected behavior and steps to reproduce the issue.

expected behavior

I have a few pending transactions. They have a low fee and will need days to get confirmed.

A few days later I add a new transaction. The new transaction should be added to my local list of pending transactions. Drop any other transaction but not one of my pending transactions.

actual

The new transaction gets droped. Logfile Transaction pushed out because of limit (hash x, replacement: y). UI message Dropped because of queue limit. Never ever drop any local transaction!

steps to reproduce

I did not try to reproduce it. I don't want to lose more pending transactions. I guess the following steps are needed:
1.) Add a transaction with the lowest possible fee.
2.) Restart node? The restart will load the transaction from disk. Maybe any important information gets lost?
3.) Wait until the mempool is full / configurate a tiny limit.
4.) Add a few more transaction and wait for the first transaction to get dropped.

config

[parity]
mode = "active"
auto_update = "none"
#no_persistent_txqueue = true
#public_node = true

[account]
disable_hardware = true

[rpc]
#interface = "local"
#cors = ["null"]
#server_threads = 4
#processing_threads = 16

[ipc]
path = "\\\\.\\pipe\\jsonrpc.ipc"

[ui]
force = true

[network]
no_serve_light = true
warp = true

[footprint]
pruning_history = 8
pruning_memory = 1
cache_size = 32768
db_compaction = "ssd"
scale_verifiers = true
num_verifiers = 16

[misc]
#logging = "rpc=trace"
log_file = "C:\\DEV\\Parity.log"

[Tbaut]

Can you confirm that you are sending transactions with Parity UI?
Can you precise how you launch parity (which flags/toml file)?

[littleskunk]

Config added above.

I am sending transactions with web3. web3.eth.accounts.privateKeyToAccount(...).signTransaction(...) and web3.eth.sendSignedTransaction(...)

On the logfile they are listed as local transactions. Local tx ... below minimal gas price accepted
I can track the progress on parity UI. It is showing them as pending the same way a transaction send with parity UI would look like.

[Tbaut]

You can use the following flags to adapt your configuration to your needs:

    --tx-queue-mem-limit=[MB]
        Maximum amount of memory that can be used by the
        transaction queue. Setting this parameter to 0 disables
        limiting. (default: 4)

    --tx-queue-size=[LIMIT]
        Maximum amount of transactions in the queue (waiting to be
        included in next block). (default: 8192)

    --tx-queue-per-sender=[LIMIT]
        Maximum number of transactions per sender in the queue. By
        default it's 1% of the entire queue, but not less than 16.

    --tx-queue-gas=[LIMIT]
        Maximum amount of total gas for external transactions in
        the queue. LIMIT can be either an amount of gas or 'auto'
        or 'off'. 'auto' sets the limit to be 20x the current block
        gas limit. (default: off)

    --tx-queue-strategy=[S]
        Prioritization strategy used to order transactions in the
        queue. S may be: gas_price - Prioritize txs with high gas
        price (default: gas_price)

You'll find here some more interesting flags such as --min-gas-price to accept low gas txs: https://wiki.parity.io/Configuring-Parity

[littleskunk]

@Tbaut Thank you. I know all these flags but that doesn't change my expectation. There are ~8192 transaction on the list. A few hundert are mine. Drop one of the remaining 8000 transactions but don't drop my own transaction.

Min gas price doesn't matter for this. I could set it to a low value, add a few transaction, restart with a higher value and would still expect them to get broadcasted and not dropped.

[tomusdrw]

@littleskunk the new queue has additional limits, as seen in the docs. In your case most likely you need to increase --tx-queue-per-sender.
Local transactions are always prioritized, but we never allow them to exceed defined limits (why set limits otherwise?).
If you don't want to propagate non-local transactions feel free to increase min-gas-price - your transactions will get to the pool despite the gas price being low, but others will be rejected.

[littleskunk]

the new queue has additional limits, as seen in the docs. In your case most likely you need to increase --tx-queue-per-sender.

In that case send me an error on the new transaction and don't drop the old transaction. If I am not watching my logfile i would not get any notification. That is not acceptable.

If you don't want to propagate non-local transactions feel free to increase min-gas-price - your transactions will get to the pool despite the gas price being low, but others will be rejected.

You are missunderstanding me. I want to propagate non-local transactions. Thats the reason I am running with default settings. I want to prioritize local transactions but that is not the case. In this issue my local transaction was not prioritized and dropped!

Maybe an easy to understand example to explain this:
You open you bank account and send out some FIAT transactions to pay bills. One hour later you remember that you forgot one bill. Login again and send out the missing one. A few weeks later they kick you out of your apartment because your bank dropped one of the pending transactions without any notification. That is not acceptable.

[littleskunk]

Meanwhile I will run a test with --tx-queue-per-sender=8192. That could be a good workaround. I would not call it a fix. I would expect an error message. Don't drop my local transaction silently. (Better don't drop them at all. Accept the new transaction and broadcast them all even if they exceed any limit. Priotize them over any limit)

[tomusdrw]

@littleskunk ok, sorry for misunderstanding. Your description suggest that the new transaction just got rejected because of limit. Was one of your previous transactions pushed out by a non-local transaction?
That should be addressed in #8691 and released with 11.3. Possibly #8980 might be related, but I would need some more detailed logs.

To be clear: we never intend to drop existing local transactions. However there are two cases where we might do that:

1. You are sending a replacement transaction (same sender&nonce, gas price higher by at least 12.5%)
2. You've sent a future transaction first (nonce=N+1), and then you are sending a transaction that should go before that one (nonce=N) - in that case, if the queue is full the future one will be dropped in favour of the second transaction.

[littleskunk]

Was one of your previous transactions pushed out by a non-local transaction?

No. My previous transaction was pushed out by my new transaction.

You are sending a replacement transaction (same sender&nonce, gas price higher by at least 12.5%)

I checked both transactions. They have different sender.

You've sent a future transaction first (nonce=N+1), and then you are sending a transaction that should go before that one (nonce=N) - in that case, if the queue is full the future one will be dropped in favour of the second transaction.

I checked that as well. The old transaction was not a future transaction. All of my pending trasactions have a different sender. I am using an HDKey for that.

I should be able to reproduce that. My script can regenerate the old transaction. Which loglevel would you like to see?

[tomusdrw]

@littleskunk Ok, that's clear now. Let me add a test for that case and fix the issue.

[debris]

Closing as I believe it was fixed in #9002