SERVER-130600 introduced a fallback mechanism to skip oplog scanning when initializing fast count metadata or when trying to advance the last valid-as-of timestamp when there is no persisted valid-as-of timestamp and scanning the oplog would block advancing the timestamp/block startup. The ticket added logs here and here indicating when this happens, and indicating that fast count is likely to be incorrect as a result.

We should set up an ingestion rule around this or an alarm so that we can detect when customers run into this.