-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: 8.3.0-rc0
-
Component/s: Catalog, Upgrade/Downgrade
-
None
-
Catalog and Routing
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Implement a test hook that validates the schema of the shard catalog, i.e. ensures there are no missing or additional fields, and that they are of the expected type/range, consistently with the current FCV.
Why this is important: Current multiversion testing focuses on adjacent FCV or binary versions (e.g. FCV 8.0↔9.0 on binary 9.0, or binary 8.0↔9.0 on FCV 8.0). A schema inconsistency may not cause an issue in those tests, but it may do across larger gaps.
For example: We may remove a field from the catalog in FCV 9.0. If that field is not re-added when downgrading to FCV 8.0, it will likely not cause tests to fail since binary 9.0 supports the field not being present even in FCV 8.0. But it would become a problem if the binary is downgraded to binary 8.0 and it expects the field to be present.
It would also spot races of FCV upgrade/downgrade with catalog changes, e.g. SERVER-88964, SERVER-118421.
How this could be done: The existing catalog_list_operations_consistency_validator.js test hook already lists all catalog fields, but it's overly generic and does not take FCV into account. We could consider refactoring that hook to tighten the validations.
- is derived by
-
-
- Closed
-
- is related to
-
SERVER-118421 Catalog changes during setFCV can race with rename across DBs
-
- Backlog
-
-
-
- Closed
-
- related to
-
SERVER-85320 Investigate testing gap for binary upgrade
-
- Open
-
-
SERVER-90768 Compare output between listCollections and $listCatalog for the same database and verify equivalence in testing
-
- Closed
-