When creating a child context, we do not prune / delete it in case of failure / reversion prior entering this new context. This causes these stale contexts to remain in memory, especially in MemAfter, which is then not empty for the last segment, because next context creation will hop over this past max context id. You can test it easily with block 1033 of the test chain for instance, though several blocks would be triggered on develop (since latest PR, this will panic with wire set twice as the table is expected to be empty, but just looking at the trace lengths will highlight it).
For instance in create_common, for the first txns of this block, we'll be hitting a collision, jumping to %create_collision and reverting to the past checkpoint, but the unused new context will remain (and so will be the associated metadata for largest context ID). We could possibly add some journaling entry for context creations, though this may have some side effects that I haven't foreseen yet, and I'm flying tomorrow morning without my laptop.
sai-deng
commented
3 days ago
Quoted from @Nashtare in a Slack discussion: