-
Type: Engineering Test
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Catalog
-
Catalog and Routing
-
Fully Compatible
-
CAR Team 2024-08-19, CAR Team 2024-09-02, CAR Team 2024-09-16, CAR Team 2024-09-30, CAR Team 2024-10-14, CAR Team 2024-10-28, CAR Team 2024-11-11, CAR Team 2024-11-25
-
200
-
2
The listCollections command is the public interface for listing the collections and their collection options. The listCollections command is used by systems designed to sync data such as
- logical initial sync
- chunk migration
- resharding (and moveCollection, unshardCollection)
- mongodump
It is problematic if there are collection options which aren't included in the listCollections output which upon creating the collection would result in the new instance of the collection not correctly responding to all future read and write requests.
To detect gaps in what is reported in the public listCollections interface I'd propose adding logic to jstests/hooks/validate_collections.js (which is already run by resmoke fixtures after each test and mongo shell fixtures on shutdown) to compare the output between it and the $listCatalog interface. This would almost have surely caught SERVER-90243.
- is related to
-
SERVER-82221 listCollections and listIndexes should include commit-pending namespaces
- Closed
-
SERVER-90243 ShardCollection/Chunk Migrations/Resharding do not clone some collection catalog options.
- Closed
-
SERVER-60574 Add a new catalog flag to indicate whether a time-series bucket has mixed-schema data
- Closed
-
SERVER-76258 Flag when time-series granularity isn't modified after collection creation
- Closed
-
SERVER-82235 Make logical initial sync use $listCatalog instead of listDatabases/Collections/Indexes
- Blocked
- related to
-
SERVER-92275 Improve test to check that list collections is consistent with the durable catalog
- In Progress
-
SERVER-90899 Metadata consistency checker must look for additional catalog inconsistencies
- Closed