-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Catalog and Routing
-
🟦 Shard Catalog
-
None
-
None
-
None
-
None
-
None
-
None
Creating a shard-local or temporary collection can install an UNTRACKED token in the CSS even when the shard is not the database primary. That leaves CSS in a state that checkMetadataConsistency treats as inconsistent under 9.0 FCV with authoritative shards: UNTRACKED is only valid on the DB primary shard.
Under 8.0 FCV this was accepted by design. ShardServerOpObserver::onCreateCollection still installs CollectionMetadata::UNTRACKED() for several creation paths that do not follow the sharding protocol, including temporary collections (options.temp) and other local/implicit creates.
Metadata consistency checks currently swallows those cases via isNamespacePermittedToHaveUntrackedCssInconsistency so known-by-design noise does not fail the check.
This ticket tracks making those creations stop installing UNTRACKED in CSS when the collection is shard-local and does not honor the sharding protocol, so the swallow list can be removed.
Known creation paths that hit this today:
- Direct shard connections creates that bypass mongos.
- Internal creates (e.g. via DBDirectClient).
- Temporary collections: $out staging, convertToCapped tmp, rename tmp, and collections with temp: true in collection options.
Note: This ticket is marked as an Improvement because it makes the shard catalog model easier to use and understand. Leaving UNTRACKED in the CSS for temporary collections is already handled internally and has been proven correct.
- related to
-
SERVER-133296 Investigate why CheckMetadataConsistency should not swallow UNTRACKED CSS for timeseries buckets collections
-
- Closed
-
-
SERVER-133353 Clear CSS metadata when dropping shard-local collections created outside the sharding protocol
-
- Needs Scheduling
-