In 5.0 we extended the DatabeVersion with a new field: a timestamp. The idea was that this timestamp would replace another field: the uuid. As part of the setFCV(5.0) command, we patched up the information on the CSRS and asked all shards to refresh, patching up their routing and filtering information.

However, we didn't think about what happened with mongos: it could totally happen that we had a mongos under FCV 5.0 sending commands with DBVersions that didn't have timestamps. However that was not a problem because the DatabaseVersion class wasn't assuming that the timestamp was mandatory, so if it wasn't present that class was relying on the epoch field.

The problem was introduced in 5.1, when we changed the implementation of the DatabaseVersion to assume that the Timestamp was always present. The problematic scenario is when we are replacing the binaries: first we change the ones on the shards and afterwards the ones on the mongoses. Thus, it could happen that one of those stale mongoses send a command with a version that doesn't have timestamps to a shard that it is expecting them.