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

Change streams should emit drop event for collection rename events that drop a collection

    • Type: Icon: New Feature New Feature
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Query Execution

      I am running into strange behaviour when using $out with change streams and it sounds like this is things working as designed, but I am filing this ticket because I suspect this design will lead to many more people having critical bugs in their application. 

       

      TLDR: 

      1. A customer used $out instead of $merge
      2. We open a cluster-wide change stream that filters on `ns: {$in: { "LIST OF NAMESPACES"}}`
      3. This filter misses the rename event
      4. The customer ended up in a divergent state in which both the old data and new data existed in the collection because we misunderstoo what would happen in this case 

       

      The events this generates: 

      {
        _id: {
          _data: '82675C848C0000001B2B022C0100296E5A100424918F5F57784EC7B4E5BBDD69F4AE7C46645F69640064675C848593B096FC7ECC51D00004'
        },
        operationType: 'insert',
        clusterTime: Timestamp({ t: 1734116492, i: 27 }),
        fullDocument: { _id: ObjectId("675c848593b096fc7ecc51d0"), a: 'bar coll' },
        ns: {
          db: 'db1',
          coll: 'tmp.agg_out.d57e4987-4225-40a2-9785-8135cc1c6448'
        },
        documentKey: { _id: ObjectId("675c848593b096fc7ecc51d0") }
      }
      {
        to: { db: 'db1', coll: 'foo' },
        _id: {
          _data: '82675C848C0000001C2B022C0100296E5A100424918F5F57784EC7B4E5BBDD69F4AE7C04'
        },
        operationType: 'rename',
        clusterTime: Timestamp({ t: 1734116492, i: 28 }),
        ns: {
          db: 'db1',
          coll: 'tmp.agg_out.d57e4987-4225-40a2-9785-8135cc1c6448'
        }
      } 

      Note that when using a collection level change stream, this does result in an invalidate event, but not for DB or Cluster change streams. 

      I strongly suspect that lots of people and applications are susceptible to this issue as lots of documentation and tutorials suggest filtering on the NS field. 

      It sounds like new work was done so that when using showExpandedEvents the Rename event explicitly states if there was an existing collection that was dropped or if it was empty, but I don't think that addresses the issue that many might just miss this event entirely.

      I guess my question is, what is the downside of issuing a collection drop event in this case? 

            Assignee:
            Unassigned Unassigned
            Reporter:
            tyler.kaye@mongodb.com Tyler Kaye
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: