In a world where an invalid view exists in the view catalog for a database:
Concurrent dropCollections for the same namespace will fail due to an invalid view definition. If a collection is successfully dropped the first time, the happy path will not conflict with the view catalog. The second time, since we don't find the collection in the catalog, we assume that we have a view instead. We attempt to look up said view, causing the invalid view definition error even if said view doesn't exist.
This behavior breaks the invalid system views contract, which is that an invalid view in the view catalog should not interfere with attempting to run operations on unrelated collections.
It's possible just to make a first pass through the view catalog to verify if a view exists without validating durable views, then to make another pass with validation on if the view does indeed exist.
- has to be done before
-
SERVER-42000 Remove blacklist for invalid_system_views_sharded_collection.js after next 4.2 release
- Closed