It can be convenient to allow MDB nodes to allow inserts into the oplog (and is even necessary for some current restore procedures). But oplog entries being inserted with a bad (stale) timestamp trip this fassert.
The fassert is important for correctness of the typical writes replication performs against the oplog (that are still on behalf of a user operation). But there is hopefully a path for validating these timestamps.
Perhaps a strict validation that an oplog entry's ts field is larger than the current top of oplog? With an exception for an explicit `ts: Timestamp(0, 0)` as I expect the server to be choosing TopOfOplog + 1.