Geth-statediff doesn't save storage if value is empty #57
Labels
No Label
bug
critical
duplicate
enhancement
epic
help wanted
in progress
invalid
low priority
question
rebase
v1
v5
wontfix
Copied from Github
Kind/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: cerc-io/go-ethereum#57
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System information
Geth
Version: 1.10.1-statediff-0.0.15
Git Commit:
daa2cdde22
Git Commit Date: 20210313
Architecture: amd64
Go Version: go1.15.5
Operating System: linux
Expected behaviour
In
storage_cids
table should be row with non-emptystorage_leaf_key
and mhKey should point toblock
table with RLP encoded empty stringActual behaviour
In
storage_cids
table there is a row with emptystorage_leaf_key
and mhKey points toblock
table with emptydata
fieldSteps to reproduce the behaviour
setMessage
function and pass empty string as inputHere JSON-RPC request to verify against geth leveldb:
Replace
0xafD0849Ee466Ef3232896DB4D41871566Fc7d028
with your address of deployed contractRelated to https://github.com/vulcanize/ipld-eth-indexer/issues/72
Per out conversation in slack: zeroed values aren't stored in the trie, the real issue is that we are not correctly signifying when a zero-value node at a specific leaf key is pruned away (due to not including the leaf_key for the removed node in the row representing it)
To fix we should include the leaf key in the removed-node-type entries. mhKey should still be empty since there is technically no node at that path that we should be referencing, we are just signifying that a node has been removed.
We also need to a script to update the current entries in our db0
Fixed in #58 , although I will open a separate issue to track the separate script for repairing the current db.
Also of note, the fix is for both state and storage tries