[SERVER-58975] ChangeStreams behave abnormally on DB with same name as destroyed DB Created: 30/Jul/21 Updated: 16/Sep/21 Resolved: 16/Sep/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 4.4.6 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Eric Vergnaud | Assignee: | Edwin Zhou |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Steps To Reproduce: | 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.
|
| Participants: |
| Description |
|
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. |
| Comments |
| Comment by Edwin Zhou [ 16/Sep/21 ] |
|
We haven’t heard back from you for some time, so I’m going to close this ticket. If this is still an issue for you, please provide additional information and we will reopen the ticket. Best, |
| Comment by Edwin Zhou [ 07/Sep/21 ] |
|
We still need additional information to diagnose the problem. If this is still an issue for you, would you please the changestream behavior output during the first and second instances of the changestream and database? Can you also provide a script that demonstrates the behavior you're observing? Best, |
| Comment by Edwin Zhou [ 23/Aug/21 ] |
|
Thank you for your patience while I investigate this issue. To help further investigate and reproduce this issue, can you provide the changestream behavior output during the first and second instances of the changestream and database? Can you also provide a script that demonstrates the behavior you're observing? Best, |