Closed offerm closed 5 years ago
Hi @offerm, that isn't actually a Raiden error. The actual error message
{'code': -32000, 'message': 'missing trie node d74423b54378a6d49546847401bb01798f2ac01f8f0a9ba47ed8a5b26c20ef4c (path )'}
is produced by your Ethereum node.
From a bit of googling this is most likely caused by fast-syncing your Eth node: https://github.com/ethereum/go-ethereum/issues/16123
@ulope thanks. I'm using a private ETH chain running locally. The geth
process is not mining so there are not additional blocks.
When I start the master
I constantly get this error. However, when I start an older branch there is no error.
How can this be related to Eth node if I'm using the same node for both branches?
@ulope more information:
If I change raiden/blockchain/state.py:26
from
channel_details = payment_channel_proxy.detail(opened_block_hash)
to
channel_details = payment_channel_proxy.detail('latest')
everything works.
This line was changed (from latest
to opened_block_hash
) by @LefterisJP on 2019-02-18.
My concern is that the open_block_hash
is wrong.
Let me know if you need any other information.
Note that now, after I started raiden with channel_details = payment_channel_proxy.detail('latest')
I don't see the problem any more even after changing the line back to channel_details = payment_channel_proxy.detail(opened_block_hash)
I guess that once the blockchain event was handled there is no need to handle it again.
To recreate the problem I remove the datadir
and restart.
My concern is that the
open_block_hash
is wrong.
Can you add a breakpoint to /Users/admin/raiden/raiden/blockchain_events_handler.py:89
before the call of get_channel_state()
and inspect the value of the blockhash? The data is retrieved from the ethereum event.
Sure.
I see there blockNumber
: 6414 and block_hash
: '0xb3e09a099579b2ea8b5fa8f872e2c559514b787ec8f53650ded440ab6f89611b'
Information looks consistent. Not sure that the channel created in that block.
> eth.getBlock(6414)
{
difficulty: 1665051,
extraData: "0xd983010814846765746888676f312e31312e328664617277696e",
gasLimit: 8000000,
gasUsed: 109923,
hash: "0xb3e09a099579b2ea8b5fa8f872e2c559514b787ec8f53650ded440ab6f89611b",
logsBloom: "0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000c000000000000040000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000500000000000000100000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000040000000001000000000000000000000010000000000002000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000000000",
miner: "0x4f6799e2341379ea52213919622b9bec80a1b655",
mixHash: "0x9291f3b0b571498d47d434ac21fbe43ebafbca5013c5e7e183e41d5375ba05dc",
nonce: "0x01dd2067f6ff45dc",
number: 6414,
parentHash: "0x7fbf4552baa61e5ad7edfe4e6914b7a4f0d4cfc6024a1495306363cb62266441",
receiptsRoot: "0xfade99ec95d46a72f5b67518d9de131641b8726577d4a7f0497e4e03bef3817f",
sha3Uncles: "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
size: 747,
stateRoot: "0xd74423b54378a6d49546847401bb01798f2ac01f8f0a9ba47ed8a5b26c20ef4c",
timestamp: 1550160798,
totalDifficulty: 4543987762,
transactions: ["0x3ec4eb59f2f10159a50196b7105fe67f1d0a4560f5ceaff4746914f242cd686e"],
transactionsRoot: "0x9c0a323f65ae148215d025915c72b952a27acc7469a90c8a090df8a0b5f1f371",
uncles: []
}
Hmm okay this looks wrong. Is the block_hash
a hexadecimal string at the point I asked you to put the breakpoint? It should be bytes
after this change. Are you sure you are properly rebased on master?
I tried it on Kovan by putting a breakpoint on latest master while it processes blockchain events and the blockhash there is indeed bytes.
Sorry. Yes, it is bytes there. I used event.event_data['block_hash'].hex()
@LefterisJP note that the error is
`{'code': -32000, 'message': 'missing trie node d74423b54378a6d49546847401bb01798f2ac01f8f0a9ba47ed8a5b26c20ef4c (path )'}`
the hex string d74423b54378a6d49546847401bb01798f2ac01f8f0a9ba47ed8a5b26c20ef4c
is probably taken from stateRoot
of block 6414. (see above)
From what I read, geth 1.8.0 is using state pruning and only keeping the last 128 states. This is probably the reason why we see this error when asking for block 6416 and the chain is at 7542.
Is it safe to use the historical block without checking that the state is available? Maybe use 'latest' in case of a too old block?
@offerm indeed that must be it. I ran some tests. Made an issue for this: https://github.com/raiden-network/raiden/issues/3566
With latest master, after erasing the
datadir
, I'm getting this: