From e1673c16226d610b39cf95e6038cd728bbfbc15a Mon Sep 17 00:00:00 2001 From: CPerezz Date: Wed, 8 Apr 2026 12:04:28 +0200 Subject: [PATCH] trie/bintrie: wrap DeleteAccount error with address context DeleteStorage, UpdateStorage, and UpdateContractCode all wrap the underlying InsertValuesAtStem/Insert error with the offending address ("(%x) error: %v"). UpdateAccount is the lone outlier and DeleteAccount inherited that pattern. When InsertValuesAtStem fails deep inside the recursion (e.g. a HashedNode resolver error), "which address" is exactly the context the caller wants. Match DeleteStorage, the closest sibling. --- trie/bintrie/trie.go | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/trie/bintrie/trie.go b/trie/bintrie/trie.go index a1f5b57a4c..db680e3b15 100644 --- a/trie/bintrie/trie.go +++ b/trie/bintrie/trie.go @@ -331,7 +331,10 @@ func (t *BinaryTrie) DeleteAccount(addr common.Address) error { values[accountDeletedMarkerKey] = zeroBlob[:] t.root, err = t.root.InsertValuesAtStem(stem, values, t.nodeResolver, 0) - return err + if err != nil { + return fmt.Errorf("DeleteAccount (%x) error: %v", addr, err) + } + return nil } // accountDeletedMarkerKey is the stem offset used as a "this account was