[SERVER-23224] Remove obsolete ShardRegistry::QueryResponse::opTime field from ShardRegistry::QueryResponse Created: 18/Mar/16 Updated: 02/Jun/16 Resolved: 02/Jun/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Esha Maharishi (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Sprint: | Sharding 16 (06/24/16) |
| Participants: |
| Description |
|
It's the return value of ShardRegistry::_exhaustiveFindOnConfig, which is called down the chain by CatalogManagerReplicaSet::_exhaustiveFindOnConfig, which extracts the ShardRegistry::QueryResponse::opTime and returns it as StatusWith<OpTimePair<vector<BSONObj>>>. CatalogManagerReplicaSet::_exhaustiveFindOnConfig has a lot of callers, some of which have invariants on the returned opTime. |
| Comments |
| Comment by Andy Schwerin [ 02/Jun/16 ] |
|
This isn't in the way of anything. If it ever prevents other refactoring or new code, we can do it then. |
| Comment by Randolph Tan [ 11/Apr/16 ] |
|
spencer The if statement in ChunkManager does not provide us full protection because it is possible for older data to have newer opTime. This is because the opTime returned in the metadata is the opTime after performing the read and is designed specifically for guaranteeing that if you use that opTime for readAfterOpTime, you will never get back in time reads. So, I propose we get rid of that check since it gives us a false sense of security. |
| Comment by Spencer Brody (Inactive) [ 11/Apr/16 ] |
|
esha.maharishi, did we determine that we can't do this because it's still used in the ChunkManager loading code? https://github.com/mongodb/mongo/blob/master/src/mongo/s/config.cpp#L419-L421 CC renctan |