[SERVER-34710] Add test for resuming a change stream after an "invalidate" from a dropCollection Created: 26/Apr/18 Updated: 06/Dec/22 Resolved: 31/May/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Ian Boros | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | todo_in_code | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Query
|
||||||||||||
| Backport Requested: |
v4.0
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
Trying to resume a changeStream without a specific collation on a collection that has been dropped will currently trigger an error since there is the UUID provided by the resumeToken will not be in the server's catalog, and so the server won't know which collation to use. This code is being changed in |
| Comments |
| Comment by Nicholas Zolnierz [ 31/May/18 ] |
|
Closing as a dup of |
| Comment by Charlie Swanson [ 31/May/18 ] |
|
Yep, closing this as a duplicate of the other sounds good to me! |
| Comment by Ian Boros [ 31/May/18 ] |
|
Oh...Looks like I filed this before we agreed that resuming from an 'invalidate' should produce an error. Now that we've agreed on that behavior this ticket indeed seems like a duplicate. Closing sounds good to me. |
| Comment by Nicholas Zolnierz [ 31/May/18 ] |
|
charlie.swanson ian.boros I'm in favor of closing this as a dup of |
| Comment by Charlie Swanson [ 18/May/18 ] |
|
Bumping this to the next sprint in favor of |
| Comment by Spencer Brody (Inactive) [ 27/Apr/18 ] |
|
It should never be possible to resume a changeStream after an invalidate. |