[SERVER-34516] Resuming a change stream after a sharded collection is dropped can return incorrect results Created: 17/Apr/18  Updated: 06/Dec/22  Resolved: 20/Apr/18

Status: Closed
Project: Core Server
Component/s: Aggregation Framework
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Nicholas Zolnierz Assignee: Backlog - Query Team (Inactive)
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query
Operating System: ALL
Participants:

 Description   

There are several integration tests that hit this, marked with "TODO: SERVER-xxxx". The basic steps are as follows:

1. Shard test collection
2. Insert a document to each chunk, storing the resume token from the first
3. Drop the collection.
4. Attempt to resume using the resume token from step (2)

The expectation is that the second insert is the first result, however the change stream returns "invalidate" instead. I believe this is because mongos is not aware of the collection, so it assumes it is unsharded and only sends a getMore to the primary shard. The primary shard sees that it's next operation after the resume token is an invalidation, since the insert is on the other shard. The fix likely includes a change to the targeting logic to handle this case.

Edit: I should also mention that the behavior is different if the collection has been recreated after the drop, since mongos may target all shards in that case.



 Comments   
Comment by Andy Schwerin [ 20/Apr/18 ]

This is a bug that would hypothetically exist depending on the implementation of SERVER-32088.

Generated at Thu Feb 08 04:36:56 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.