Retrying a findAndModify can error if its oplog write was rolled back but not the post/pre image oplog entry.

For retryable findAndModify, the pre/post image is stored as a separate oplog entry with op type 'n'. This is written to the oplog before the actual update/remove oplog entry. If the secondaries were able to replicate up to the pre/post image but not the actual update/remove, it will be in an inconsistent state when it becomes the new primary at that point. Attempting to retry will fail because the server thinks that it has already executed the write, but cannot properly fetch the oplog entries because it expects both the pre/post image and update/remove oplog to exist.