Closed staffik closed 1 week ago
Attention: Patch coverage is 91.30435%
with 2 lines
in your changes missing coverage. Please review.
Project coverage is 71.61%. Comparing base (
74ac5fe
) to head (f58c2a1
). Report is 3 commits behind head on master.
Files | Patch % | Lines |
---|---|---|
chain/chain/src/chain.rs | 91.30% | 0 Missing and 2 partials :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
That sounds right. However, still looks hacky that we are doing this check for every single block, while the shard "status" changes only once per epoch.
I have a feeling that we can call retain_mem_tries
only if epoch_manager.is_next_block_epoch_start(parent_hash)
is true, and remove retain_mem_tries
from run_catchup because it doesn't fit there. Would you like to try it?
Also nit - if the function is called retain_mem_tries
, the comment should also explain why retaining happens. The fact that it mentions GC (the opposite event) is confusing.
Currently we remove obsolete memtries only when we start state sync for a new shard: https://github.com/near/nearcore/blob/master/chain/client/src/client.rs#L2507-L2519 However, it does not unload obsolete memtries in all cases. For example, if we tracked shards [0, 1, 2], and then we track shards [0, 1] only, shard 2 won't be unloaded, because we did not start a new state sync. Although it is not critical, trie for shard 2 could occupy memory forever.
This PR calls the routine to unload obsolete memtries as a block post-processing step too.