Parity-ethereum: personal_sendTransaction does not create transaction

[Dmatafonov]

_Before filing a new issue, please provide the following information._

I'm running:

• Which Parity version?:
  version Parity/v1.9.1-beta-aca9f13-20180201/x86_64-linux-gnu/rustc1.23.0

• Which operating system?: Windows / MacOS / Linux
  Ununtu

• How installed?: via installer / homebrew / binaries / from source
  Via bash

• Are you fully synchronized?: no / yes
  Yes

• Which network are you connected to?: ethereum / ropsten / kovan / ...
  Etherium

• Did you try to restart the node?: no / yes
  No

I've created transaction with RPC call personal_sendTransaction exactly the same as I was creating transaction on geth. Between two local accounts (addresses).

It returned txid to me '0xf53480b78867843a6e064f5c7d75e17751db762a02ca745c61a6fe137e0c2acf'

But looking to etherscan - there is no this transaction. And funds didnt move on local accounts either.

{"jsonrpc":"2.0","method":"personal_sendTransaction","params":[{"from":"0x92e1e0b42a05649f68beed919143cdef84dd658f","to":"0x6252a4e4a978a0e996d88d0b9054d37f069b2cf7","value":"0x1502b15302ff64"},"SOMEPASS"],"id":8}

Here is what my rpc call looks like.

And it does return txid so _looks like_ it is working as expected. But no actual transaction is created. May be I should sign it?

[5chdn]

Are you connected to any peers? Please share some logs

[Dmatafonov]

Im connected. And when I check lastblock it is one or three blocks lag from etherscan, no more. So chain is fully synced.

[5chdn]

Can you use the TXQUEUE VIEWER dapp to see what's going on? In the wallet?

[Dmatafonov]

I coulld try but I dont have graphical interphace on server and have no idea what is TXQUEUE VIEWER dapp and how to start it. My dapp folder on the server is empty.

[Dmatafonov]

Tried to get to parity wallet, but it doesnt seem to work. /rpc requests are sent via GET without any params and receive empty responce.

[Dmatafonov]

Have no idea why, but after my experiments with config, one transaction was published...
But now it doesnt publish againg - all I did is restartetd parity daemon with same params

parity daemon /dev/shm/parity.pid --log-file /var/log/parity.log --jsonrpc-apis all --jsonrpc-cors all --jsonrpc-hosts all --jsonrpc-interface all --ui-hosts all --ws-interface 94.130.167.236 --ws-apis "all" --ws-origins "all" --ws-hosts "all" --ws-port 8547

[Dmatafonov]

@5chdn Afri, any ideas on where I can dig? Dont see anything in parity.log file while creating transaction.

[Dmatafonov]

This transaction was created. Have no idea why.

https://etherscan.io/tx/0x7239bab405e9fb3b39b5dccdde61fb1a0a2a56c1dcbf4c8da63d6e22048ff7a7

But the same call just minute after, after node restart, doesnt create transaction despite I get similar result from rpc with transaction hash

https://etherscan.io/tx/0x629379acc697b9c160816d75b815bcafe9c967ce48fe475b551256c8dea4d88a

[Dmatafonov]

Upgraded parity to 1.9.2 - no effect. Doesnt work.

[Dmatafonov]

@5chdn I found your answer on stack and started txque log -ltxqueue=trace. There is like ton of logs being generated and I couldnt find anything strange at the time transaction _look like being created_

[Dmatafonov]

In -ltxqueue=debug I have found my transaction log at the moment of _creation_. Wasnt published to the blockchain anyway.

[Dmatafonov]

Ok, In signer log I have found at the moment of _creation_
WARN own_tx Transaction marked invalid (hash 286525f317d31917c3209e489a994fa14ade2b5a18e64cebdd650701acc92ba1)

But why it's invalid??

[Dmatafonov]

Same invalid status from -lown_tx=trace log

[Dmatafonov]

Holy shit. I found finally how to fix it.

Looks like some transactions are being stuck in trnsaction que. Could not find any reasons in logs why.

But. I found out how to kill that issue. I startted node with non-documented param --no-persistent-txqueue and now it works.

Guys, you should fix it somehow. My installtion wasnt somthing special, and I think it's kinda tricky to debug this level of errors without any docs on what could go wrong.

[5chdn]

Sorry, yeah I was going to suggest that. I'll discuss this with the team.

[Dmatafonov]

I would suggest sending an RPC error instead of tx_id if it is possible. Would make much more sense and make it clearer to understand if somthing went wrong, because now, receiving tx_id actually says nothing about was transaction created or not. I have to wait 30 seconds in code and then check transactionRecepit.