Currently, shard secondaries with 4.0 binary and 3.6 FCV call `_flushDatabaseCacheUpdates` against the primary node. This is wrong because the primary might be running a 3.6 binary, which doesn't have this command. As a result, in partial-upgrade cases, where a secondary node is on 4.0 and the primary is on 3.6 (with FCV 3.6), queries against the secondary will always fail with an error saying "CommandNotFound: no such command: '_flushDatabaseCacheUpdates'".

For some context:

• 3.6 - introduced the versioned secondary reads and the forceRoutingTableRefresh/_flushRoutingTableCacheUpdates commands
• 4.0 - introduced the database version concept, which ensures that all commands which read/write database and collection metadata are routed appropriately after a movePrimary or drop/recreate. This logic introduced the _flushDatabaseCacheUpdates command, which is only on 4.0, but is unconditionally called if the catalog cache is accessed on a secondary node.