Major - P3 The contracts for what different inputs to OpObserverImpl generate what oplog entries could use some hardening. The following table can be used as a starting point for what a unittest can cover (note [oplogEntry.]`NeedsRetryImage` is the only output being asserted):
| featureFlag... | storeFindAndModify... | Pre/Post | Op | NeedsRetryImage | |----------------+-----------------------+----------+--------+-----------------| | false | false | Pre | Update | boost::none | | false | false | Pre | Delete | " | | false | false | Post | Update | " | | false | false | Post | Delete | " | | false | true | Pre | Update | " | | false | true | Pre | Delete | " | | false | true | Post | Update | " | | false | true | Post | Delete | " | | true | false | Pre | Update | kPreImage | | true | false | Pre | Delete | kPreImage | | true | false | Post | Update | kPostImage | | true | false | Post | Delete | boost::none | | true | true | Pre | Update | boost::none | | true | true | Pre | Delete | " | | true | true | Post | Update | " | | true | true | Post | Delete | " |
Other inputs to consider:
- Whether a noop oplog entry containing an image should be generated for a given set of inputs
- Adding a dimension to the matrix for when a collection is configured to always record preimages.
- It's debatable if the feature flag code path is of interest. But when storeFindAndModifyImagesInOplog becomes the default with an FCV upgrade, that might be a corollary axis of input.