-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Fully Compatible
-
ALL
-
Execution Team 2021-01-25
-
12
In this test, after SERVER-50610, the logic is roughly:
- thread 0 always does inserts (with implicit createCollection) and create index on field x
- All other threads do one of dropIndex, dropCollection, or scan index x (retry if index x not there because we assume thread 0 will create an index eventually)
However, if thread 0 completes before others, all other threads could hang if the index is dropped again after.
I think maybe we could make the dropIndex thread to always recreate one after dropping the index so we don't rely on tid:0 being there to create the index. In other words, we probably should never have dependencies between threads in FSM because some of them might finish before others.
- related to
-
SERVER-50610 secondary_reads.js should not make assertions based on natural collection ordering
- Closed