Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-66335

Make change streams robust to future no-op oplog collisions

    XMLWordPrintableJSON

Details

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major - P3 Major - P3
    • None
    • None
    • None
    • None
    • Query Execution

    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.

      Attachments

        Activity

          People

            backlog-query-execution Backlog - Query Execution
            bernard.gorman@mongodb.com Bernard Gorman
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated: