With SERVER-67962, on secondaries we implemented a solution to handle deletes / implicit inserts to the config.image_collection within a single oplog applier batch. This means that secondaries parse oplog entries (derived inserts or explicit deletes) to config.image_collection.

In the linked BF, the fuzzer inserted a nonsense entry into config.image_collection and then deleted it. I don't think this is legal behavior. But this resulted in the crash of the secondary.

I think we should add a check to the write path to prevent writes on the config.image_collection collection, or prevent the fuzzer from producing such cases. (We might also want to prevent writes to other implicitly replicated collections such as system.preimages).

To repro, run the following on the replica set primary. You will see that the secondary has crashed.

> use config
> db.image_collection.insert({_id: 2, a: 3});
> db.image_collection.remove({}, {writeConcern: {w: 1}}); // {w: 1} is optional, but we do it so that the command returns even though the secondary crashes.