MongoDB 4.0 does not provide versions for admin and config databases. This information has been introduced in MongoDB 4.2 and the management of local sessions needs to known the version of the config database.

A problem occurs during the upgrade process, where the binaries of the secondary shards are upgraded before the primary (as suggested in the migration guide). In this scenario, the config database metadata update is implicitly triggered by session management at the secondary shard level (MongoDB 4.2), but this information is not provided by the primary shard as it does not yet support it (MongoDB 4.0).

It follows the detailed workflow that triggers the problem:

1. After a binary upgrade to version 4.2, the secondary shard forces a config database metadata refresh
2. The secondary shard accesses to SSCCL and forces a refresh on primary, thus waits for replication
3. The primary shard (version 4.0) accesses to SSCCL which forwards a request of metadata update to the config server through the CSCCL
4. CSCCL intercepts that the request is related to the special database (i.e. config) and returns a built-on-fly database type (without version as that’s a shard version 4.0)
5. The secondary shard receives the replication and finds incomplete database metadata in locally-persisted cache (i.e. config.cache.databases)

When the problem is triggered, the following error appears in the logs: InternalError: DatabaseVersion doesn't exist in database entry { _id: "config", partitioned: true, primary: "config" } despite the shard being in binary version 4.2 or later.