fix(aich): self-heal LoadHashSet offset cache on successful rewind - #193
Merged
got3nks merged 1 commit intoJun 17, 2026
Merged
Conversation
PR amule-project#191 added a defensive rewind so LoadHashSet finds the right entry even when the cached offset is stale (known2.met modified externally between cache load and the request). The rewind worked but didn't update the cache: every subsequent LoadHashSet for the same stale root hash kept paying the seek-miss + full linear scan, instead of the O(1) cache hit the cache exists to provide. The cache only self-cleared on daemon restart, on CEOFException-driven truncation, or after an orphan-prune rewrite in CAICHSyncTask -- none of which fire just because a single entry's offset went stale. When the rewind succeeds, the linear scan has just found the right position for the root hash. Stamp it back into s_rootHashCache so future lookups for the same hash go straight there. Capture the entry's start position pre-read (entryStartPos) so we have the exact offset of the root hash, matching the value LoadRootHashCacheLocked and SaveHashSet write into the cache.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #191.
#191 added a defensive rewind so
LoadHashSetfinds the right entry even when the cached offset is stale (known2.metmodified externally between cache load and the request). The rewind worked, but it didn't update the cache after recovering — so every subsequentLoadHashSetfor the same stale root hash kept paying the seek-miss + full linear scan instead of the O(1) cache hit the cache exists to provide.The cache only self-cleared on daemon restart, on
CEOFException-driven truncation, or after an orphan-prune rewrite inCAICHSyncTask::Entry()— none of which fire just because a single entry's offset went stale.What this changes
In the match handler inside
LoadHashSet:entryStartPos) so we know the exact offset of the root hash — matching the valueLoadRootHashCacheLockedandSaveHashSetwrite into the cache.cacheFallbackTriggered == true), stamp the new offset back intos_rootHashCache. Future lookups for the same hash go straight to the right offset.Total diff is 12 lines added.
Verification
The fast-path (cache fresh, first read matches) is unchanged:
cacheFallbackTriggeredstaysfalse, so the cache-update branch is skipped. Self-heal cost is one mutex lock + one map write, only on the rewind path, only on successful recovery.