I found that there are a few int64s that are uninitialized and can possibly be written to the logs. This will show very large numbers of keysInserted for update operations when only a single document is updated in the logs and can be confusing to users leading them to believe that a replaceOne() on a single document leads to billions of updates.

Examples:

https://github.com/mongodb/mongo/blob/f1090ddbcc24bf61bdadc937c8bdd483878b49cf/src/mongo/db/catalog/collection_impl.cpp#L1207 

https://github.com/mongodb/mongo/blob/f1090ddbcc24bf61bdadc937c8bdd483878b49cf/src/mongo/db/catalog/collection_impl.cpp#L838 

https://github.com/mongodb/mongo/blob/f1090ddbcc24bf61bdadc937c8bdd483878b49cf/src/mongo/db/catalog/index_catalog_impl.cpp#L1348 

to name a few. This specific scenario might be hard to reproduce since the bug in reporting happened while 83 write conflicts occurred.

The relevant query is:

> db.c.drop()
> db.c.insert([{x: 1, y: 1}, {x: 2, y: 2}])
> db.c.replaceOne({x: 999, y: 999}, {x: 999, y: 999}, {upsert:true})

The goal of this ticket is to write a test to reproduce this scenario, initialize the vars that account for the keysInserted and show that we no longer report uninitialized data.