Currently, mongod sometimes sets shardVersion UNSHARDED and does filtering metadata checks. If the filtering metadata is "unknown", the mongod can return StaleConfig to the client. Make sure to handle config.system.sessions, which gets automatically sharded by the config server. Also always return "ok" for the dbVersion check if needed.

Until user collections can be sharded in serverless, the sessions collection (config.system.sessions) will be the only sharded collection. While the architecture contains Atlas Proxy, shardsvrs must return unsharded metadata to avoid returning StaleConfig from the shardVersion check, since Atlas Proxy does not know how to handle StaleConfig. However, the logical session cache refresh and reap on internal nodes will load the sessions collection's real routing metadata and attach a real shardVersion on their requests to this node. So, for the sessions collection, this node must return its real routing metadata. It's ok if this node hasn't loaded the real routing metadata yet: this node will load the real routing metadata and return StaleConfig, and the sending node will handle StaleConfig by refreshing its routing metadata and retrying.