The following tests fail on 2.4:

• FindOneAndReplace when no documents match with upsert returning the document before modification
• FindOneAndReplace when no documents match with upsert returning the document after modification

When asserting the collection outcome, the newly upserted document contains a generated ObjectId instead of 4. Evidently, findAndModify on 2.4 and earlier disregards the filter when it yields no match and an upsert is requested with a full replacement document (i.e. no atomic operators). The issue seems specific to dealing with replacement documents, as the corresponding findOneAndUpdate() tests do not have this issue.

A work-around would entail duplicating the ID in our replacement document.