In the current resharding coordinator design there is a limitation that in a window between commit of the temporary collection to the global catalog and the recipient shard accepting the remote command, fetching the latest data from the global catalog, the temporary collection cannot be found by anyone. This happens since qccording to the routing information it exists in recipient shard, however recipient shard haven't fetched the authoritative meta information for this collection and contradicts the routing information. Therefore for any incoming request the recipient shard responds with kUnknown sharding state which causes StaleConfig and forces the router request to retry.

Sometimes these indefinite retries can lead to timeouts which can be a cause of BFs. Example: BF-45760. So, in order to avoid them, we should simply exclude the temporary resharding collections from periodic background jobs from router, as for external user this collection is either way inaccessible.