Module rehydration leads to leaks
The current strategy of module rehydration leads to leaks where there are multiple copies of a ModDetails
alive for certain modules.
Consider this module structure
┌───────┐ ┌───────┐
│ │ │ │
│ A │ │ B │
│ │ │ │
└─────┬─┘ └───┬───┘
│ │
┌────▼─────────▼──┐
│ │
│ C │
└────┬─────────┬──┘
│ │
┌────▼──┐ ┌───▼───┐
│ │ │ │
│ A-boot│ │ B-boot│
│ │ │ │
└───────┘ └───────┘
When we rehydrate A, C and A-boot
together then A
will be checked against a fresh copy of C
s ModDetails.
Later when we rehydrate B, C and B-boot
together then B
will be checked against a fresh version of C
s details and so there will now be two copies of C
s details, one referenced from A
and one from B
.
In order to avoid this leak when we rehydrate B, C, and C-boot
we should also rehydrate A
in this loop because A
depends on a module which we are rehydrating and so needs to be checked against the new version of the ModDetails in order to avoid duplicating ModDetails.