_Before filing a new issue, please provide the following information._
I'm running:
- Which Parity version?: 1.8.3
- Which operating system?: Linux
- How installed?: via installer
- Are you fully synchronized?: yes
- Did you try to restart the node?: yes
_Your issue description goes here below. Try to include actual vs. expected behavior and steps to reproduce the issue._
Using a synchronized parity I sent a transation and waited for the receipt. But the transaction seems to be never broadcasted. At least etherscan was not able to find it.
Now resending this transaction does not work:
Error importing transaction: Transaction(AlreadyImported)
So this also means any other transaction form the same account will fail:
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. {}
This means the user can not send any transaction anymore since this transaction was not broadcasted.
Deleting the chaindata, resyncing and the sending the transaction again works fine, but if there a way reset or resend these already imported transactions? and why does this happen?
Make sure you are connected to peers and the gas price is high enough. The error indicates that the transaction is already in the queue. You can get rid of it by restarting with --no-persistent-txqueue.
Same here, I really don't know why it's happening, confusing. Trying broadcast signed tx from etherescan, and from myetherewallet. Then creating parity node and trying same thing through it, result is same, no success silently. Any tx isn't broadcasting even smart contract execution (here is my test smart contract 0xf8967e9d70b6bda12ed5db727c2d55c004564046)
@khaschuluu Can you elaborate more on your case? It seems different than this one - do you see AlreadyImported in your logs? Feel free to create a new issues to start the discussing.
I am just syncing a node and constantly get streams of:
Error importing transaction: Transaction(AlreadyImported)
With an occasional correct import.
Occurs in 1.7.6 and 1.8.3
I solved it. My last txs stacked on my broken node (on geth), and I starts new node on parity and above problems appears. And it's fixed when I recreate tx with fee is greater than before (overwrite tx nonce). In last few days, ethereum average tx fee is up and some new tx (pending) are stacks with message like underprice, fee is too low etc. and then, after txs can't broadcast, because tx nonce isn't match. Thanks guys. I think it isn't issue, it's about broken tx problem. If someone meet this problem, please overwrite last pending tx (same nonce) with greater gas price (avg. network price is good for it).
Whilst transactions may be failing to import due to reused nonces, my company operates a number of public nodes and at the moment the console is filled with these error messages. This is no real issue (apart from looking messy). The problem is that the pending transactions API calls return empty responses during this.
It would seem there is a bug of some sort with the importing of pending transactions from the network.
I get this error in Metamask with every first transaction I make (e.g. every time I load the page with a fresh parity chain booted). Once I disconnect (i.e. choose a new provider) and reconnect, every transaction works fine.
I am also getting this on a backend process for every transaction I make - I have not been able to get one through yet.
The error is very perplexing. I added --no-persistent-txqueue to no avail.
I'm using v1.8.4 with instant sealing and both --reseal-on-txs all, and --force-sealing flags.
For anyone who stumbled on this: in my case, this message seemed to be a blanket statement for any failed transactions. I had an error on my side -- once I fixed it this message went away.
Any further update on this from the Parity devs?
Having upgraded to the 1.8.6 BETA my mainnet node still looks like this:

@tomusdrw can we close this since we have a new transaction pool?
Closing regardless because it's a misconfiguration error, solution is improved documentation.
The link to improved part of documentation would be nice. It would be hard to go through all the docs to figure it outt
If you have the time I would be appreciative to understand why this was considered a misconfiguration error? and what the new transaction pool means in practice? A link to the improved documentation would also be appreciated.
Here is the documentation about the new Tx queue
May I know in which version was the new Tx queue released? Or what commit/PR is it if not released yet?
in 1.11