Possible bug in clone logic #1155

Activity

1. benjello

   added

   level:advancedRequires substantial OpenFisca experienceRequires substantial OpenFisca experience

   kind:fixBugs are defects and failure demand.Bugs are defects and failure demand.

   on Oct 19, 2022
2. bonjourmauko commented on Dec 6, 2022

   

   bonjourmauko

   on Dec 6, 2022

   Member

   More actions

   Thanks @nikhilwoodruff .

   @benjello at first I thought this was a duplicate of #848 , yet reading both issues, it appears like the behaviour described here is intended. Do you confirm?
3. benjello commented on Dec 7, 2022

   

   benjello

   on Dec 7, 2022

   Member

   More actions

   I think the behaviour expected by @nikhilwoodruff should be enforced.

   👍React with 👍1Reacted by Thomas Guillet
4. Adelagric

   added a commit that references this issue on Sep 9, 2026

   Fix Simulation.clone sharing mutable state with the original

   ...

   This issue will close once commit 4d68f7d is merged into the 'master' branch.

   4d68f7d
5. Adelagric commented on Sep 9, 2026

   

   Adelagric

   on Sep 9, 2026

   Contributor

   More actions

   Hi! I believe I found the mechanism behind this, and it turned out to be four compounding defects rather than one. @nikhilwoodruff's intuition about members was correct — the cloned group population keeps the original persons as members — but it was only part of the picture:

   1. Holder.clone shares the holder's InMemoryStorage/OnDiskStorage by reference, so any input set, value cached or array deleted through the clone silently alters the original (and can leave it internally inconsistent: fresh input, stale cached results).
   2. GroupPopulation.clone calls holder.clone(self) instead of holder.clone(result), so the clone's group-entity holders are bound to the original population and simulation.
   3. GroupPopulation.clone reuses self.members (your observation).
   4. The clone shares _data_storage_dir, so with a memory_config active, holders lazily created on both sides write their .npy files into the same directory — one simulation reads the other's values, and garbage-collecting either one deletes the other's files.

   I have a minimal reproduction for each, and a PR with a fix and regression tests: #1385.
6. Adelagric

   added 2 commits that reference this issue on Oct 2, 2026

   Fix Simulation.clone sharing mutable state with the original

   ...

   This issue will close once commit 2e97b42 is merged into the 'master' branch.

   2e97b42

   Fix Simulation.clone sharing mutable state with the original

   ...

   This issue will close once commit 70abbea is merged into the 'master' branch.

   70abbea
7. guillett

   added a commit that references this issue on Oct 9, 2026

   Fix Simulation.clone sharing mutable state with the original

   ...

   This issue will close once commit 0245358 is merged into the 'main' branch.

   0245358
8. guillett

   added 3 commits that reference this issue on Oct 19, 2026

   Fix Simulation.clone sharing mutable state with the original

   ...

   This issue will close once commit eadb093 is merged into the 'main' branch.

   eadb093

   Fix Simulation.clone sharing mutable state with the original

   ...

   This issue will close once commit 0c5b6f8 is merged into the 'master' branch.

   0c5b6f8

   Fix Simulation.clone sharing mutable state with the original

   ...

   This issue will close once commit 3bced49 is merged into the 'main' branch.

   3bced49
9. Adelagric

   added a commit that references this issue on Oct 26, 2026

   Fix Simulation.clone sharing mutable state with the original

   ...

   This issue will close once commit ee3bd05 is merged into the 'master' branch.

   ee3bd05