MB-70770: Race between delete introductions and in-mem merge#2303
MB-70770: Race between delete introductions and in-mem merge#2303abhinavdangeti wants to merge 2 commits intomasterfrom
Conversation
A possible bug in scorch where concurrent deletions of nested documents were lost during in-memory segment merges, leading to inflated document counts after an index reload.
|
@CascadingRadium @Thejas-bhat would you share your opinion(s) on the validity of the test case here and that this could possibly be the situation caught in our testing. |
abhinavdangeti
changed the title
|
My reasoning is pretty much the same as I had put in #2295. Like during persist, any deletes that came in and updated the root would have created a new index snapshot altogether which will be persisted + updated in bolt as part of the next cycle right? My thinking is that the snapshot between the step 5 and step 6 in your test isn't the snapshot that's being persisted but rather a new snapshot altogether created independent of the persister's view. If we update the view of the persister itself before the cycle completes, I think we'd not be maintaining a consistent view of the system for the worker/actor to work upon. Like if the next persist cycle didn't persist the deleted information of the introduceMerge() then we can say that the persister is not handling the deletes properly. please let me know if this makes sense. from a code coverage perspective, i think we should have this test in our repo. |
|
#vibecoding failed 😞 |
3 participants
A possible bug during ingestion where concurrent deletions of documents were lost during in-memory segment merges, leading to inflated document counts after an index reload.