In the router role, when the CollectionRouter encounters a StaleConfig, it determines whether the shard-role or the router-role needs to refresh by comparing the wanted version with the received version.

If both shard versions exist and represent the same incarnation of the collection, the shard is considered stale if the wanted version is older than the received version. Conversely, if the wanted version is newer, the router is deemed stale.

For example, let's say the wanted version is {0,0}, indicating that the shard has no chunks, while the received version is {11,0}. When comparing these shard versions, the shard will be considered stale (since wanted < received). Consequently, the shard-role will catch the StaleConfig exception and update the shard to install the new filtering metadata. After this, the shard will retry the operation with the up-to-date filtering metadata.

There are two possible scenarios:

1. The shard is actually stale: If the wanted version is now {11,0}, the retry will proceed successfully.
2. The shard is not stale: If the wanted version remains {0,0}, this indicates that the router is the one that is stale. If the router is a remote node, it will refresh and retry successfully. However, if the router is local, it will not explicitly refresh the routing information because it believes the router is stale.

In the second scenario, there is currently no bug because refreshing the filtering metadata triggers a refresh of the CatalogCache. This process allows the router-role to recognize the newer shard version, which will be utilized for the received version.

Once SERVER-95393 is committed, the filtering metadata will not refresh the routing information, resulting in a StaleConfig being bubbled up to the user. This only applies for {0,0} wanted shard version because it is not comparable.