After PM-1950, change streams consumes various no-op oplog messages to detect the completion of certain events, such as shardCollection or refineCollectionShardKey. These are written as command-style objects in the o2 field of the oplog entry, e.g.

{ ... o2: {shardCollection: "db.coll", shardKey: {a: 1}}}

The change stream filter matches these events by checking for the existence of the command name in the o2 field. This means that, if future authors of no-op oplog entries include fields with these command names in their o2 entry, they will inadvertently cause change streams to erroneously match these no-op events.

We should come up with a more robust way of preventing this, perhaps by adding a default-false parameter to the no-op oplog API which specifies whether or not the no-op message is intended for consumption by change streams, and if not tasserts that the o2 message does not collide with any fields that are reserved by change streams.