
OPERATIONAL DEFECT DATABASE
...

...
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 Take DDL lock check bucketsNs shardVersion create bucketsNs check viewNs shardVersion create viewNs 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.
MongoDB Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.