The find command (and presumably any other command that needs to resolve UUIDs to namespaces), can return a NamespaceNotFound error on a collection that is concurrently renamed within the same database. If we try to execute a find command by UUID for a collection that exists but is being concurrently renamed, there is a race condition due to the fact that the find command resolves UUIDs to namespaces outside of its locks. For example, consider the following execution for a find and renameCollection command running on separate threads:
Although accesses to the UUIDCatalog are made atomic by the catalog lock, different commands may still interleave their operations on the catalog in an arbitrary order, if not protected by stronger (database or collection level) locks.
Attached is a repro (find_by_uuid_and_rename.js) demonstrating this issue. The race condition appears to be very narrow. Its probability is increased by adding a short sleep immediately after this line. Adding a mongo::sleepmillis(50) seemed sufficient.
- is related to
-
SERVER-34531 listDatabases command can miss a database if a collection in that database is renamed concurrently
- Closed
- related to
-
SERVER-29839 Protect against UUID->NSS mapping changing after looking it up in all commands that use parseNsOrUUID
- Closed
-
SERVER-37384 Find by UUID must not return NamespaceNotFound without taking any database lock
- Closed
-
SERVER-33632 Make UUID catalog reload atomic
- Closed