If a mapReduce runs in FCV 3.4, the temp collection will automatically pick up the collection options from the out collection, if the out collection exists. If we're running concurrent mapReduces, the out collection has a chance to exist. Take this scenario:
Steps to reproduce (sequentially):
- MapReduce 1 creates an out collection "xyz" with a generated UUID "a."
- MapReduce 2 (same in/out) creates a temp collection that uses the same UUID "a" picked up from the now-existing "xyz."
- The out collection "xyz" gets dropped.
- MapReduce 2 renames the temp collection to "xyz." It will have the same UUID "a."
We should not be propagating UUIDs in this fashion.
The relevant code is here
- related to
-
SERVER-36701 Concurrent mapReduce replace with setFCV between 3.4 and 3.6 can cause errors with UUID assignment/removal
- Closed