fix encoding when storage is empty #94
No reviewers
Labels
No Label
bug
critical
documentation
duplicate
enhancement
Epic
good first issue
help wanted
Integration tests
invalid
question
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/ipld-eth-server#94
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "empty_data_encoder"
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?
Looks good, just a few questions/comments.
So just to double check and make sure I follow, an empty 32 byte slice is what geth would return here?
@ -438,9 +441,11 @@ func (r *IPLDRetriever) RetrieveAccountByAddressAndBlockHash(address common.Addr
if err := r.db.Get(accountResult, RetrieveAccountByLeafKeyAndBlockHashPgStr, leafKey.Hex(), hash.Hex()); err != nil {
Just to note, we should only ever see a zero value for a node that is not "Removed" if we are at a block height prior to EIP-158 activation (which is when zeroed value pruning begun). Does this make sense, and align with what we are seeing?
I think we need the analogous check in the account retrieval methods above (
RetrieveAccountByAddressAndBlockNumber
andRetrieveAccountByAddressAndBlockHash
) and the other storage retrieval method below (RetrieveStorageAtByAddressAndStorageKeyAndBlockNumber
).@ -438,9 +441,11 @@ func (r *IPLDRetriever) RetrieveAccountByAddressAndBlockHash(address common.Addr
if err := r.db.Get(accountResult, RetrieveAccountByLeafKeyAndBlockHashPgStr, leafKey.Hex(), hash.Hex()); err != nil {
We're running a local/private chain for which the value in genesis is
"eip158Block": 0,
, so this isn't consistent with what we expect?yes
@ -438,9 +441,11 @@ func (r *IPLDRetriever) RetrieveAccountByAddressAndBlockHash(address common.Addr
if err := r.db.Get(accountResult, RetrieveAccountByLeafKeyAndBlockHashPgStr, leafKey.Hex(), hash.Hex()); err != nil {
Where is
RetrieveAccountByAddressAndBlockNumber
function called? I couldn't find it. And how to test account deleting?@ -438,9 +441,11 @@ func (r *IPLDRetriever) RetrieveAccountByAddressAndBlockHash(address common.Addr
if err := r.db.Get(accountResult, RetrieveAccountByLeafKeyAndBlockHashPgStr, leafKey.Hex(), hash.Hex()); err != nil {
It makes sense but doesn't align with current behavior. Isn't this misalignment was introduced here in this PR https://github.com/vulcanize/go-ethereum/pull/58 ?
@ -438,9 +441,11 @@ func (r *IPLDRetriever) RetrieveAccountByAddressAndBlockHash(address common.Addr
if err := r.db.Get(accountResult, RetrieveAccountByLeafKeyAndBlockHashPgStr, leafKey.Hex(), hash.Hex()); err != nil {
Hmm I need to think about this some more, sorry, let me get back.
@ -438,9 +441,11 @@ func (r *IPLDRetriever) RetrieveAccountByAddressAndBlockHash(address common.Addr
if err := r.db.Get(accountResult, RetrieveAccountByLeafKeyAndBlockHashPgStr, leafKey.Hex(), hash.Hex()); err != nil {
I think we want to fix the function even if it isn't currently called. We could test account deleting similar to how we do it here: https://github.com/vulcanize/go-ethereum/blob/v1.10.7-statediff/statediff/builder_test.go#L1318
@ -438,9 +441,11 @@ func (r *IPLDRetriever) RetrieveAccountByAddressAndBlockHash(address common.Addr
if err := r.db.Get(accountResult, RetrieveAccountByLeafKeyAndBlockHashPgStr, leafKey.Hex(), hash.Hex()); err != nil {
If that is the cause of the misalignment then all we need to do is check that the node isn't a "Removed" type when we query for the latest value at a given path/key, which I think we are already doing?
@ -438,9 +441,11 @@ func (r *IPLDRetriever) RetrieveAccountByAddressAndBlockHash(address common.Addr
if err := r.db.Get(accountResult, RetrieveAccountByLeafKeyAndBlockHashPgStr, leafKey.Hex(), hash.Hex()); err != nil {
@arijitAD is taking over here, to echo what I told him in slack:
First thing to do is verify that we are excluding "Removed" type nodes when we perform those queries.
If we arent doing that then we are actually just seeing null values where they are supposed to be, and need to add a check to filter those out
But I think we are already filtering out "Removed" nodes in those queries, and if we are already doing that then there is some deeper reason as to why we are seeing null values for nodes that are not of the "Removed" type
Another possible lead is how we (and geth) are distinguishing (or not) between true nulls and legitimate zero values
@ -438,9 +441,11 @@ func (r *IPLDRetriever) RetrieveAccountByAddressAndBlockHash(address common.Addr
if err := r.db.Get(accountResult, RetrieveAccountByLeafKeyAndBlockHashPgStr, leafKey.Hex(), hash.Hex()); err != nil {
On the other side of this coin, if 0 values are not showing up when they are supposed to it is likely because the query being made against the database does not properly consider the "Removed" node type entries as indicating a 0 value and instead the query finds the last entry where the node is not "Removed" and returns that latest non-zero value (which is the behavior we want in some cases, but not here).
@ -438,9 +441,11 @@ func (r *IPLDRetriever) RetrieveAccountByAddressAndBlockHash(address common.Addr
if err := r.db.Get(accountResult, RetrieveAccountByLeafKeyAndBlockHashPgStr, leafKey.Hex(), hash.Hex()); err != nil {
Please see https://github.com/vulcanize/ipld-eth-server/issues/95#issuecomment-918202095 there is a much simpler fix now that we have leaf_key for "Removed" nodes
Added migration https://github.com/vulcanize/statediff-migrations/pull/19
Looks good but see https://github.com/vulcanize/statediff-migrations/pull/19#discussion_r715925284, we can improve the stored function we are using to determine if a contract was destroyed or not.
Done
Do the unit tests here test the new function in both contexts (when the contract has been destroyed at that height and when it hasn't)? If so, good to go, if not let's add that.
Yes, It checks before destroying the contract and after it is destroyed.