Currently, in the write phase for updateOne/deleteOne/findAndModify without shard key, mongos replaces the original filter from the client with the _id of the document that it finds in the find phase. The fact that the target shard doesn't receive the original filter is problematic for the purpose of query sampling and shard key analysis.

Consider a collection containing documents with two fields "x" and "y". The user workload involves only updateOne that filters by "y". However, they didn't know about that and sharded the collection on {x: 1}. So now every write is an updateOne without shard key. Due to the overwriting of filter, every write that a shard receives has the filter {_id: ...} and that's what gets written down to the config.sampledQueries collection. Now when the user runs analyzeShardKey to analyze the shard key {y: 1}, they would see that every write is a scatter gather and single write without shard key and conclude that the shard key is bad. Or more generally, in this scenario, all shard keys except {_id: 1} would have equally bad metrics.

Given this, the write phase should set the filter to the _id plus the original filter.