ChangeStreams behave abnormally on DB with same name as destroyed DB

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Done
    • Priority: Major - P3
    • None
    • Affects Version/s: 4.4.6
    • Component/s: None
    • None
    • ALL
    • Hide

      Create a replica set "MY-RS".

      Create a DB "TEST" .

      Implement a change stream for collection "INSTANCES" using a locally cached timestamp for "startAtOperationTime".

      Store a bunch of records in collection "INSTANCES", the change stream behaves nominally.

      Stop the change stream.

      Destroy the DB "TEST".

      Create a new DB "TEST".

      Implement a change stream for collection "INSTANCES" using a locally cached timestamp for "startAtOperationTime".

      Store a bunch of records in collection "INSTANCES", the change stream behaves abnormally, not receiving all changes.

       

      Show
      Create a replica set "MY-RS". Create a DB "TEST" . Implement a change stream for collection "INSTANCES" using a locally cached timestamp for "startAtOperationTime". Store a bunch of records in collection "INSTANCES", the change stream behaves nominally. Stop the change stream. Destroy the DB "TEST". Create a new DB "TEST". Implement a change stream for collection "INSTANCES" using a locally cached timestamp for "startAtOperationTime". Store a bunch of records in collection "INSTANCES", the change stream behaves abnormally, not receiving all changes.  
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      ChangeStreams that use a startAtOperationTime or resumeAfter or startAfter do not receive all changes if the DB was created using the same name as a previously destroyed DB.

            Assignee:
            Edwin Zhou
            Reporter:
            Eric Vergnaud
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: