When a resharding operation is aborted, donor shards can be left with tracked metadata in the CSS for the temporary namespace system.resharding.<uuid> even though that namespace no longer exists in the global catalog.

Non-authoritative path (8.0 FCV)
Donors install CSS for the temporary namespace by refreshing its filtering metadata. On abort, the donor clears that CSS, then force-refreshes both the source namespace and the temporary namespace. Refreshing the temporary namespace reinstalls tracked CSS while that collection is still present in config.collections. After participants finish abort cleanup, the coordinator removes the temporary collection from the global catalog, leaving the donor with stale tracked CSS.

Authoritative path (9.0 FCV)
On abort, the donor clears in-memory CSS and does not refresh the temporary namespace. However, donors never drop the temporary namespace's durable shard-catalog metadata on abort. (Donors only do that on the successful commit path for non-recipient shards.) Any durable leftover can later surface again as tracked CSS.

 Notes

• Any CSS clear on the primary must also be replicated to secondaries. In the non-authoritative model, that happens when exiting the critical section (FilteringMetadataClearer). In the authoritative model, it happens through the shard-catalog commit helpers and the corresponding oplog c entries.
• The practical impact of leaving stale CSS for this namespace is minor: the temporary resharding collection is not targetable by users or mongos, and a later resharding operation will use a different temporary namespace. Still, abort cleanup should leave the shard catalog in a clean state by design.