[SERVER-35999] A $changeStream can trigger assertion on UUID check when the collection cache is stale Created: 06/Jul/18 Updated: 16/Jul/18 Resolved: 16/Jul/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | 3.6.5 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Nicholas Zolnierz | Assignee: | Nicholas Zolnierz |
| Resolution: | Duplicate | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Sprint: | Query 2018-07-30 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
UUIDs were introduced in v3.6, however after upgrading from 3.4 it's possible that the collection state in-memory cache contains an entry for the collection (meaning it's sharded) but does not contain a UUID. As such, this assertion will fail when a $changeStream compares the UUID from the oplog entry to the UUID in the collection state cache. Edit: Since change streams requires readConcern majority, the secondary will perform a shard version check but not necessarily refresh its cache. For change streams, mongos will not attach a shard version which means that the version check will always pass and no refresh is performed. |
| Comments |
| Comment by Nicholas Zolnierz [ 16/Jul/18 ] |
|
There won't be any changes to the aggregation/$changeStream side of this issue, so marking as a duplicate of |
| Comment by Ian Whalen (Inactive) [ 13/Jul/18 ] |
|
First step is just to write a repro to aid the conversation with Sharding about where the problem is. |