[SERVER-66335] Make change streams robust to future no-op oplog collisions Created: 10/May/22  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Bernard Gorman Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query Execution
Participants:

 Description   

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.



 Comments   
Comment by Arun Banala [ 10/May/22 ]

One way to achieve this is to add an Enum describing all the no-op oplog entries, and add a debug assertion in this function to validate that every no-op oplog entries belongs to the enum.

Generated at Thu Feb 08 06:05:08 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.