Scrub pre-existing orphaned config.tags entries for timeseries collections during v9.0 FCV upgrade

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Catalog and Routing
    • 🟥 DDL
    • None
    • None
    • None
    • None
    • None
    • None

      Background

      Two bugs allowed config.tags (zone tag) documents to become orphaned for viewful timeseries collections:

      • SERVER-127450 (fixed, merged to master): In mixed-version clusters with a pre-9.0 mongos, reshardCollection for a timeseries collection used the bucket namespace (db.system.buckets.coll) as sourceNss. On resharding commit, writeDecisionPersistedState only deleted config.tags entries for the bucket namespace, leaving entries under the user-facing namespace (db.coll) orphaned.
      • SERVER-128947 (fix pending): DropCollectionCoordinator::removeTagsMetadataFromConfig has the same namespace mismatch — a plain drop of a viewful timeseries collection calls removeTagsMetadataFromConfig with the bucket namespace, leaving any zone tags stored under the user-facing namespace orphaned.

      Both fixes are forward-looking only — they prevent new orphans from being created but do not clean up orphans that already exist in config.tags.

      Why This Matters on v9.0 Upgrade

      Pre-existing orphaned entries are dormant in pre-9.0 FCV clusters: routing still uses the bucket namespace, so the orphaned user-facing namespace entries are never matched. When a cluster upgrades to v9.0 FCV, timeseries becomes viewless and config.tags lookups shift to the user-facing namespace. At that point, any orphaned entries become live — the balancer will find them and incorrectly apply the stale zone constraints to any collection subsequently created with the same name.

      Proposed Fix

      Add a scrubbing step to the v9.0 FCV upgrade path in TimeseriesUpgradeDowngradeCoordinator (src/mongo/db/global_catalog/ddl/timeseries_upgrade_downgrade_coordinator.cpp). This coordinator already performs namespace migrations (see updateZonesInTransaction), making it the natural home for this cleanup.

      The scrub should run after updateZonesInTransaction has migrated zone tags for all live collections. At that point, any remaining config.tags entries under a user-facing namespace with no corresponding collection in config.collections are definitionally orphaned. The scrub should:

      1. Scan config.tags for entries whose namespace does not match the system.buckets.* pattern (i.e., user-facing namespaces).
      2. For each such entry, check whether a corresponding collection exists in config.collections under either the user-facing namespace or its derived bucket namespace (system.buckets.<coll>).
      3. If neither exists, the entry is an orphan — remove it.

      This correctly targets the entries left behind by SERVER-127450 (resharding cleanup missed the user-facing namespace) and SERVER-128947 (drop cleanup missed the user-facing namespace), while leaving valid zone tags for live collections untouched.

      Related

      • SERVER-127450 — resharding variant of the namespace mismatch (fix merged)
      • SERVER-128947 — drop variant of the namespace mismatch (fix pending)

            Assignee:
            Unassigned
            Reporter:
            Anja Kalaba
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: