The applyOps command generates an oplog entry without a UUID so, in rs_rollback.cpp, we will crash when we try to dereference an optional UUID type during rollback of an applyOps oplog entry.

This is an example of a raw applyOps oplog entry that contains two document inserts.

{  "ts" : Timestamp(1506545010, 7),  "t" : NumberLong(1),  "h" : NumberLong("1630858374415394653"),  "v" : 2,  "op" : "c",  "ns" : "admin.$cmd",  "wall" : ISODate("2017-09-27T20:43:30.627Z"),  "o" : {  "applyOps" : [ { "op" : "i", "ns" : "test.coll", "o" : { "_id" : 0 } }, { "op" : "i", "ns" : "test.coll2", "o" : { "_id" : 0 } } ],  "$readPreference" : {  "mode" : "secondaryPreferred" },  "$db" : "admin" }

Rollback should treat applyOps oplog entries as special cases that don't require collection UUID oplog entry fields (there may be multiple operations, each with a different collection UUID, so it wouldn't really make sense for the applyOps entry to have a collection UUID).