Closed Trisfald closed 1 month ago
Tested with the following procedure:
Verify that
curl -X POST http://35.204.169.85:3030 \
-H "Content-Type: application/json" \
-d '
{ "id": "dontcare", "jsonrpc": "2.0", "method": "query", "params": { "account_id": "b001b461c65aca5968a0afab3302a5387d128178c99ff5b2592796963407560a", "block_id": 109913260, "request_type": "view_account" } }'
returns an error
Stop neard
Verify that
./neard view-state -t cold view-trie --shard-id 2 --shard-version 1 --max-depth 1000 --hash 36SkUU8tgetUtVL2a5JPwKB6F29yKBFjF5PFukZ8HRFH --from b001aea591ef68681e59a4149b1ab8bc56d8f22e34be24 --to b001c0de4c6929c5289b65044249830466ffea27680bc1 --format pretty --record-type account
Gives MissingTrieValue
error
Run
./neard view-state -t cold --readwrite apply-range --start-index 109913255 --end-index 109913260 --shard-id 2 --storage trie-free --save-trie cold sequential
Now step 3 doesn't fail anymore
Start neard
Step 1 returns the same result as read RPC
Attention: Patch coverage is 49.62963%
with 136 lines
in your changes missing coverage. Please review.
Project coverage is 71.68%. Comparing base (
55d0df0
) to head (4ca19f4
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
I'm very confused :)
You're storing the trie changes (
DBCol::TrieChanges
) but as far as I know this column is only used for garbage collection and cold migration. In particular I don't think it's used for answering rpc or viewing state with neard subcommands. I thought you'll be storing the trie nodes directly into theDBCol::State
column which is where I believe the data is missing. That being said it seems like it worked somehow :) Can you have a look into how this works and explain it briefly for me?
Yes, I'm saving the trie changes explicitly although I believe it isn't strictly required.
From my understanding trie changes isn't the only column touched by this section of code https://github.com/near/nearcore/blob/master/chain/chain/src/store/mod.rs#L2533-L2550, for example insertions into DBCol::State
and changes to memtries
.
Updated PR:
save-trie
for hot DB: too dangeroussave_trie_changes
to false, no need to write into this columnTODO:
save-trie
on different heights / shards combinationsOn the positive side: recovered data is still present after leaving the node running over the weekend. Regenerating trie nodes is idempotent.
Not so positive: apply-range
does not work at all for many ranges of blocks after 1st and 2nd resharding. The reason is that "missing trie values" break the apply stage of transactions. We'll need to proceed step by step and redo resharding before replaying blocks.
Overall I haven't found any inherent issue with this PR
Adds a new argument to
apply
andapply range
commands to save computed trie nodes into hot or cold storage. Normally, this operation should be idempotent, but it can also be used to reconstruct missing trie nodes.