Parity-ethereum: Parity fails returning tx receipt (truffle)

Created on 5 Apr 2017 · 12Comments · Source: openethereum/parity-ethereum

Let me introduce everyone:

Parity/v1.7.0-unstable-801a2339e-20170331/x86_64-macos/rustc1.16.0
Truffle v3.2.1
issue in the truffle repo: https://github.com/trufflesuite/truffle/issues/389

Additionally I am using geth attach ... for the tests.

How to reproduce:

parity --chain dev --jsonrpc-apis web3,eth,net,personal,parity,parity_set,traces,rpc,parity_accounts --unlock 0x0061... --password pwd.txt -lrpc=trace

> eth.getBlock('latest', true)
{
  author: "0x0000000000000000000000000000000000000000",
  difficulty: 131072,
  extraData: "0xd5830107008650617269747986312e31362e30826d61",
  gasLimit: 6000000,
  gasUsed: 0,
  hash: "0x4d8dd9d36985b507dcc269ffb059d95979c5b96830c502bcee3aaa4c7b1b31f8",
  logsBloom: "0x00000...000000",
  miner: "0x0000000000000000000000000000000000000000",
  number: 8,
  parentHash: "0x81065fa8b6f88f7d6807aa99950e449ee0995c4a438641b4620373b4dae13bbd",
  receiptsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  sealFields: [],
  sha3Uncles: "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
  size: 491,
  stateRoot: "0x3c6fccd4d6b839c18afeab81325a351f67c1bf7b8f1709cb73f40e1e56c5f389",
  timestamp: 1491384871,
  totalDifficulty: 1179648,
  transactions: [],
  transactionsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  uncles
: []
}

truffle migrate --verbose-rpc

Details from truffle:

  > {
   >   "jsonrpc": "2.0",
   >   "id": 6,
   >   "method": "eth_sendTransaction",
   >   "params": [
   >     {
   >       "from": "0x00611c69c94d39bf9a8cd5867e633603b9e84186",
   >       "gas": "0xbebc200",
   >       "gasPrice": "0x174876e800",
   >       "data": "0x606060405234<trucated...>"
   >     }
   >   ]
   > }
 <   {
 <     "jsonrpc": "2.0",
 <     "result": "0xd534dd0e57f8590f11abfd529730fd05750baa1a949e2bcceac07f3b0f269e00",
 <     "id": 6
 <   }
   > {
   >   "jsonrpc": "2.0",
   >   "id": 7,
   >   "method": "eth_newBlockFilter",
   >   "params": []
   > }
 <   {
 <     "jsonrpc": "2.0",
 <     "result": "0x0",
 <     "id": 7
 <   }
   > [
   >   {
   >     "jsonrpc": "2.0",
   >     "id": 8,
   >     "method": "eth_getFilterChanges",
   >     "params": [
   >       "0x0"
   >     ]
   >   }
   > ]
 <   [
 <     {
 <       "jsonrpc": "2.0",
 <       "result": [
 <         "0x4d8dd9d36985b507dcc269ffb059d95979c5b96830c502bcee3aaa4c7b1b31f8"
 <       ],
 <       "id": 8
 <     }
 <   ]
   > {
   >   "jsonrpc": "2.0",
   >   "id": 9,
   >   "method": "eth_getTransactionReceipt",
   >   "params": [
   >     "0xd534dd0e57f8590f11abfd529730fd05750baa1a949e2bcceac07f3b0f269e00"
   >   ]
   > }
 <   {
 <     "jsonrpc": "2.0",
 <     "result": null,
 <     "id": 9
 <   }

on the parity side:
2017-04-05 11:41:55 TRACE rpc Request: {"jsonrpc":"2.0","id":6,"method":"eth_sendTransaction","params":[{"from":"0x00611c69c94d39bf9a8cd5867e633603b9e84186","gas":"0xbebc200","gasPrice":"0x174876e800","data":"0x..."}]}. 2017-04-05 11:41:55 DEBUG rpc Response: Some("{\"jsonrpc\":\"2.0\",\"result\":\"0xd534dd0e57f8590f11abfd529730fd05750baa1a949e2bcceac07f3b0f269e00\",\"id\":6}"). 2017-04-05 11:41:55 TRACE rpc Request: {"jsonrpc":"2.0","id":7,"method":"eth_newBlockFilter","params":[]}. 2017-04-05 11:41:55 DEBUG rpc Response: Some("{\"jsonrpc\":\"2.0\",\"result\":\"0x0\",\"id\":7}"). 2017-04-05 11:41:55 TRACE rpc Request: [{"jsonrpc":"2.0","id":8,"method":"eth_getFilterChanges","params":["0x0"]}]. 2017-04-05 11:41:55 DEBUG rpc Response: Some("[{\"jsonrpc\":\"2.0\",\"result\":[\"0x4d8dd9d36985b507dcc269ffb059d95979c5b96830c502bcee3aaa4c7b1b31f8\"],\"id\":8}]"). 2017-04-05 11:41:55 TRACE rpc Request: {"jsonrpc":"2.0","id":9,"method":"eth_getTransactionReceipt","params":["0xd534dd0e57f8590f11abfd529730fd05750baa1a949e2bcceac07f3b0f269e00"]}. 2017-04-05 11:41:55 DEBUG rpc Response: Some("{\"jsonrpc\":\"2.0\",\"result\":null,\"id\":9}"). 2017-04-05 11:41:56 TRACE rpc Request: [{"jsonrpc":"2.0","id":10,"method":"eth_getFilterChanges","params":["0x0"]}]. 2017-04-05 11:41:56 DEBUG rpc Response: Some("[{\"jsonrpc\":\"2.0\",\"result\":[],\"id\":10}]"). 2017-04-05 11:41:56 TRACE rpc Request: [{"jsonrpc":"2.0","id":11,"method":"eth_getFilterChanges","params":["0x0"]}]. 2017-04-05 11:41:56 DEBUG rpc Response: Some("[{\"jsonrpc\":\"2.0\",\"result\":[],\"id\":11}]"). 2017-04-05 11:41:57 TRACE rpc Request: [{"jsonrpc":"2.0","id":12,"method":"eth_getFilterChanges","params":["0x0"]}].

from the geth console:

> eth.getTransactionReceipt('0xd534dd0e57f8590f11abfd529730fd05750baa1a949e2bcceac07f3b0f269e00')
null

the block is still the same:

````

eth.getBlock('latest', true)
{
author: "0x0000000000000000000000000000000000000000",
difficulty: 131072,
extraData: "0xd5830107008650617269747986312e31362e30826d61",
gasLimit: 6000000,
gasUsed: 0,
hash: "0x4d8dd9d36985b507dcc269ffb059d95979c5b96830c502bcee3aaa4c7b1b31f8",
logsBloom: "0x000000...00",
miner: "0x0000000000000000000000000000000000000000",
number: 8,
parentHash: "0x81065fa8b6f88f7d6807aa99950e449ee0995c4a438641b4620373b4dae13bbd",
receiptsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
sealFields: [],
sha3Uncles: "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
size: 491,
stateRoot: "0x3c6fccd4d6b839c18afeab81325a351f67c1bf7b8f1709cb73f40e1e56c5f389",
timestamp: 1491384871,
totalDifficulty: 1179648,
transactions: [],
transactionsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
uncles: []
}
````

forcing a block with a simple tx:

> eth.sendTransaction({from:eth.coinbase, to:eth.coinbase, value: 1})
"0x9913bc5d79576d2822b9d70cddd210b6ff6446255cf3091fc62e3408dc701845"

checking the block:

> eth.getBlock('latest', true)
{
  author: "0x0000000000000000000000000000000000000000",
  difficulty: 131072,
  extraData: "0xd5830107008650617269747986312e31362e30826d61",
  gasLimit: 6000000,
  gasUsed: 0,
  hash: "0xe76a86ec0793a3e04372babd313889237ff78f09c3bad3defe7597710e2033cd",
  logsBloom: "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  miner: "0x0000000000000000000000000000000000000000",
  number: 9,
  parentHash: "0x4d8dd9d36985b507dcc269ffb059d95979c5b96830c502bcee3aaa4c7b1b31f8",
  receiptsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  sealFields: [],
  sha3Uncles: "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
  size: 491,
  stateRoot: "0x3c6fccd4d6b839c18afeab81325a351f67c1bf7b8f1709cb73f40e1e56c5f389",
  timestamp: 1491385615,
  totalDifficulty: 1310720,
  transactions: [],
  transactionsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  uncles: []
}

new call:

> eth.getTransactionReceipt('0xd534dd0e57f8590f11abfd529730fd05750baa1a949e2bcceac07f3b0f269e00')
null

F2-bug 🐞 M6-rpcapi 📣

Source

chevdor

Most helpful comment

on giving it a retry, adding

[mining]
reseal_min_period = 0

to config.toml fixed the issue for me (was not running with --chain=dev but with a specific .json config

axelhodler on 15 Oct 2017

👍2

All 12 comments

Note for self: test again with -ltxqueue=trace for @tomusdrw

chevdor on 5 Apr 2017

It looks like the transaction isn't sealed into any blocks for some reason (as indicated by the empty transactions list). Getting the receipt will only work once that happens. Txqueue tracing will definitely help to diagnose.

rphmeier on 5 Apr 2017

I also think the parity UI is suffering from that same issue. If I deploy a contract, all looks ok but the contract never appears in the list of contracts. Just short on time atm but I will try getting you the Txqueue.

chevdor on 5 Apr 2017

I started parity as parity --chain dev --jsonrpc-apis net,eth,web3,personal,parity -ltxqueue=trace ui and deployed a contract:

2017-04-06 00:26:18  IO Worker #2 INFO import  Syncing      #28 08ba…a30b     0 blk/s    0 tx/s   0 Mgas/s      0+    0 Qed       #28    0/ 0/25 peers    92 KiB db   39 KiB chain  0 bytes queue 448 bytes sync  RPC:  3 conn,  9 req/s, 100 µs
2017-04-06 00:26:19   TRACE txqueue  Inserting: TransactionOrder { nonce_height: 0, gas_price: 100000000000, gas_factor: 0, gas: 173944, strategy: GasPriceOnly, hash: 056440d19b90ea264b011414e662155fe42c166888de054ad56495fa20156089, origin: Local, penalties: 0 }
2017-04-06 00:26:19   DEBUG txqueue  Imported transaction to current: 056440d19b90ea264b011414e662155fe42c166888de054ad56495fa20156089
2017-04-06 00:26:19   DEBUG txqueue  status: TransactionQueueStatus { pending: 1, future: 0 }
2017-04-06 00:26:19   TRACE txqueue  Removing old transaction: 056440d19b90ea264b011414e662155fe42c166888de054ad56495fa20156089 (nonce: 21 < 22)
2017-04-06 00:26:19   INFO own_tx  Transaction mined (hash 056440d19b90ea264b011414e662155fe42c166888de054ad56495fa20156089)
2017-04-06 00:26:23  IO Worker #0 INFO import  Syncing      #29 8222…bb25     0 blk/s    0 tx/s   0 Mgas/s      0+    0 Qed       #28    0/ 0/25 peers    94 KiB db   45 KiB chain  0 bytes queue 448 bytes sync  RPC:  3 conn, 10 req/s,  96 µs
2017-04-06 00:26:28  IO Worker #1 INFO import  Syncing      #29 8222…bb25     0 blk/s    0 tx/s   0 Mgas/s      0+    0 Qed       #28    0/ 0/25 peers    94 KiB db   45 KiB chain  0 bytes queue 448 bytes sync  RPC:  3 conn,  7 req/s,  90 µs

chevdor on 6 Apr 2017

Ok, so in the log you provided the transaction seems to be mined. Did the issue also occur in the last case?

I think on Gitter we figured out that the issue here was caused by non-mineable transaction blocking the queue and all subsequent transactions.

tomusdrw on 6 Apr 2017

Hi @tomusdrw, indeed the issue we discussed on Gitter was a blocker. I unlocked the tx but parity still seem to have the same issue than truffle. This is visible by the fact that the contracts are not registered on the contract tab. I may be wrong and that would be a second issue though.

chevdor on 6 Apr 2017

Let's close this one then and I'll open another one regarding the UI issues. Can confirm that on latest master.

tomusdrw on 6 Apr 2017

I'm running into the original problem with my Truffle migrations. It seems to be some sort of race condition where the transactions come in too fast and end up getting lost. Running Parity with --reseal-min-period 0 fixes it.

PeterBorah on 13 May 2017

@PeterBorah This should not be required in versions 1.6+ (fixed here: https://github.com/paritytech/parity/pull/4671), the setting is applied by default when running --chain=dev

tomusdrw on 15 May 2017

I am still seeing this issue on a fresh build from master

chevdor on 14 Oct 2017

same issue with v1.7.5-stable Truffle v3.4.9 although if I restart parity the first thing it will do is mine the tx which truffle was waiting for.

[...]
Operating mode: active
Configured for DevelopmentChain using InstantSeal engine
Transaction mined (hash 0a1b42458e3e586e799ca980158ca7a8...)
[...]

reverting to using plain web3js calls for deployment for now

axelhodler on 15 Oct 2017

on giving it a retry, adding