You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Quoted from @Nashtare in a Slack discussion:
The text was updated successfully, but these errors were encountered: