Starting from binary version 4.7, the configTime component of the VectorClock is used both for readPreference and readConcern on read operations sent to the configServer.

On the other hand nodes with FCV <= 4.4 are not gossiping this component of the vector clock.

So as soon as the FCV 4.4 is set on the cluster we can't rely anymore on the vector clock and we should rather use the old configOpTime stored in the Grid.

While shards are correctly relying on Grid::configOpTime() when the FCV is set thanks to this check, routers have no knowledge of FCV so the check will always pass and the last known VectorClock's configTime is going to be used (if greater than zero).

These are two possible solutions I was thinking about:

• Use always the maximum between the old configOpTime and the new VectorClock[configTime] until we completely get rid of the former (v5.1). This should be a quick fix.
• Use always the old configOpTime until we can completely switch to the new VectorClock[configTime]  (v5.1). Also this one is a quick one. Actually I'm not sure why we already started using the new VectorClock[configTime] if it is still unreliable.
• Update the VectorClock[configTime] every time the old configOpTime is advanced. Also this should be quick one but it requires to mess a bit the code of the VectorClock.