[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:
Duplicate
duplicates SERVER-36154 Shard's in-memory CSS is not refreshe... Closed
is duplicated by SERVER-35379 com.mongodb.MongoQueryException: Quer... Closed
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 SERVER-36154 as it more accurately describes the root cause and also contains the simplest repro case.

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.

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