On the authoritative path, sharding a previously-unsplittable collection appends new chunks to the shard catalog on every involved shard instead of replacing the prior ones. The DB-primary ends up with a stale chunkless_placeholder chunk entry, and the data shard ends up with the pre-shardCollection chunk entry alongside the new one/s.

Root cause

When the coordinator runs the second time (now with unsplittable=false), CreateCollectionCoordinator::_commitOnShardCatalog takes the same code path it took during the unsplittable creation:

• The data shard receives _shardsvrCommitCreateCollectionMetadata -> commitCreateCollectionLocally, which writes to config.shard.catalog.chunks.
• The DB-primary, still not in involvedShards (the only chunk is on the data shard), runs commitCreateCollectionChunklessLocally locally for the second time, also writing to config.shard.catalog.chunks.

Both helpers funnel into writeCollectionMetadataLocally, which upserts each chunk in config.shard.catalog.chunks with filter ChunkType::name() == chunk.getName() (the chunk OID). It never deletes anything. The unsplittable->sharded transition reissues OIDs, so the upsert filter never matches the prior row:

• The data shard chunk gets a new OID at the global commit, so a new row is inserted into config.shard.catalog.chunks alongside the pre-existing unsplittable-phase row.
• The placeholder is generated with a fresh OID::gen() on every call (commitCreateCollectionChunklessLocally line 367), so a second placeholder row is appended to config.shard.catalog.chunks on the DB-primary.