-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: 7.0.0, 8.0.0, 8.1.0, 8.3.0-rc0, 8.2.0
-
Component/s: None
-
None
-
Catalog and Routing
-
ALL
-
CAR Team 2025-09-29
-
0
-
🟦 Shard Catalog
-
None
-
None
-
None
-
None
-
None
-
None
In a sharded cluster, we assume DDLs happen atomically under the DDL lock, and checkMetadataConsistency depends on this in order to reliably detect inconsistencies.
In the case of the creation of an untracked collection, we take the DDL lock and assume the atomicity is due to being a single storage transaction.
However, in the case of legacy timeseries collections, the creation of the buckets collections and the timeseries view are actually two storage transactions.
In this case we relax the assumption to the operation being atomic unless there's stepdown.
However, currently the creation flow is:
- Router & filtering metadata refresh loop
If the shardVersion check in (4) fails due to needing a metadata refresh, we return to the outer loop, releasing the DDL lock. This allows checkMetadataConsistency to run the check in a partial state and report a transient MalformedTimeseriesBucketsCollection inconsistency, even though there hasn't been a stepdown and the timeseries creation will eventually succeed.
- is related to
-
SERVER-90889 Check timeseries collections throught the checkMetadataConsistency command
-
- Closed
-