If you have a recovery unit with an oplog read timestamp which is between records (that is, there is no oplog entry with that read timestamp), then a backwards seekNear on a record ID corresponding to the oplog read timestamp or any later record ID will return boost::none instead of the proper previous record.

I believe a similar problem could theoretically occur with visibility on forward searches, but it never does because WT search_near always returns the next record if it exists.