personal_sendTransaction tx not sent, stuck in parity_pendingTransactions

[dominika]

trafficstars

• Parity Ethereum version: v2.5.12-stable-29ebddc-20191216
• Operating system: Linux, x86_64-linux-gnu/rustc1.39.0
• Installation: https://releases.parity.io/ethereum/v2.5.12/x86_64-unknown-linux-gnu/parity
• Fully synchronized: yes
• Network: ethereum
• Restarted: no (we are restarting it)

We are using the personal_sendTransaction to send money from one account to the other. As a result of this JSON RPC command we have received a transaction hash.

expected behaviour the money is sent and the transaction is visible in the network using https://etherscan.io/

actual behaviour the money is not sent and the transaction is not visible in the network using https://etherscan.io/ it is not visible via transaction hash search and it is not visible when searching the https://etherscan.io/txsPending

when requesting the parity_pendingTransactions the transaction is present in the output. The sending (personal_sendTransaction) was issued more than 8 hours ago. when requesting the eth_getTransactionByHash the block number and block height are null which following the documentation https://wiki.parity.io/JSONRPC-eth-module.html#eth_gettransactionbyhash means that “blockHash: Hash - 32 Bytes - hash of the block where this transaction was in. null when its pending.”

my question is: why is it in the pending state for so long? the gas information is: "gas":"0x186a00", "gasPrice":"0x2540be400" "gas used": 0x5208 but it is not being dropped and not being send.

Could you help us out in this case?

Thank you in advance for your response

[hukkin]

I'm experiencing something similar with Parity v2.5.12 and eth_sendRawTransaction RPC call. Pushed a transaction with 8 Gwei gas price at around 2019-12-25 22:40:30 UTC. It didn't get mined in the next 50 mins until I replaced that transaction with another that had the same nonce. Most of the blocks in that 50 minute period included transactions with gas prices a lot lower than 8 Gwei, so seems to me that there is some problem in propagation with the latest stable Parity release.

[haruki515]

I'm experiencing something similar with Parity v2.5.13 and eth_sendRawTransaction RPC call. Pushed a transaction with gas price which got eth_gasPrice. it didn't get mined in the 2 days. And I rebroadcast the same raw transaction with etherscan explorer. So, the transaction has broadcasted.

[gituser]

I have the same issue on the latest v2.5.13 and it's super annoying as there is no re-send functionality at all.

Here is a workaround:

1. restart your parity with --min-gas-price 1000000000
2. grab all your tx hashes via:

curl --data '{"method":"parity_localTransactions","params":[],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST http://localhost:8545

3. then get each TX raw via

curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["<TXID>"],"id":1}' http://localhost:8545

4. submit rawtx via https://etherscan.io/pushTx

[sonofliberty]

I'm having the same issue.

My logs show this 2020-01-07 04:00:49 UTC Local tx [TXID] below minimal gas price accepted

However, the gas price was well above average. I can broadcast raw transactions that are stuck on my Parity client via Etherscan without issues.

[jam10o-new]

if you're having success propagating transactions via etherscan, and not in normal operation, it's plausible you don't have any well-connected peers.

It's not very good for the health of the network but you can have a better guarantee of your transactions reaching a etherscan-visible node by manually adding one of them from the list of nodes etherscan publishes themselves https://etherscan.io/nodetracker/nodes to your local reserved_peers

[gituser]

if you're having success propagating transactions via etherscan, and not in normal operation, it's plausible you don't have any well-connected peers.

Yes, it's very annoying as well when you have a node which is synchronized but your own transactions are not being propagated through the network.

In most cases this happens when you have less than 5 peers connected to your node. I had to forward communication port on my parity node (as I'm running it behind the NAT), and add this option as well to the parity --nat=extip:X.X.X.X.

It also might be an indication that in recent parity versions there is an issue with parity losing peers for some reason as before it worked just fine without speicifying --nat option and without communication port being forwarded to the outside world as it possess a certain risk for node operator (e.g. if there is a vulnerability found or certain DDoS attack vector).

It's not very good for the health of the network but you can have a better guarantee of your transactions reaching a etherscan-visible node by manually adding one of them from the list of nodes etherscan publishes themselves https://etherscan.io/nodetracker/nodes to your local reserved_peers

How can you be sure that this list is up to date and there is no forked nodes? Also, from other issues as far as i remember there was a recommendation not to use --reserved-peers as it might get your node stuck if there is a forked peer among those specified reserved nodes.

[tom-bgl]

It's not very good for the health of the network but you can have a better guarantee of your transactions reaching a etherscan-visible node by manually adding one of them from the list of nodes etherscan publishes themselves https://etherscan.io/nodetracker/nodes to your local reserved_peers

This worked nicely, thanks @joshua-mir, as a temporary workaround Is the root cause actually a bug in the wallet as it looks to me and suggested by others' experience too?

[jam10o-new]

it's hard to diagnose because it seems like potentially a quirk in the way our discovery interacts with the wider network - we may or may not be able to influence that.

[bfgasparin]

Any news about it? I have the same problem here.