When we perform validation on a secondary node, we set its readTimestamp to be last applied. kLastApplied can lag behind for secondaries.

Then, because we do not enforce fast count for secondaries, we always enter this block where we adjust the fast count to be the count of numRecords that we see at our read timestamp (which can have lagged).

From this patch, we see an example of this in play:

We have a collection with a single document. Then we delete that document , which sets our numRecords, and fastCount, to 0.

However, when we go to perform validation we read at a stale timestamp and see the number of records to be 1. So we then we adjust the fast count to be 1.

Then, when we resume performing operations on this collection, the fastCount is permanently one higher than it should be.

The related BFs only caught this error in multiversion suites because on 8.0 binaries we do enforce fast count on secondaries, but on master we do not.