[SERVER-83625] LookupQuerySettingsForFind should not be checking the node's sharding recovery state Created: 28/Nov/23  Updated: 17/Jan/24  Resolved: 17/Jan/24

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.3.0-rc0

Type: Bug Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Catalin Sumanaru
Resolution: Fixed Votes: 0
Labels: M3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screenshot 2023-12-15 at 14.34.02.png    
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: QE 2023-12-11, QE 2023-12-25, QE 2024-01-08, QE 2024-01-22
Participants:

 Description   

As part of SERVER-77079, the lookupQuerySettingsForFind was made to rely on the intialisation status of sharding in order to decide from where to pick up the query settings for a find.

 

Instead of relying on ShardingState API, we should check if the request comes from the internal Client. There are already similar checks throughout the codebase, such as:

bool isInternalClient(OperationContext* opCtx) {
    return opCtx->getClient()->session() && opCtx->getClient()->isInternalClient();
} 

We should do the same as part of this ticket.

 

Apart from that we should prioritize the IDHACK check, before anything else. This would speed up some of the industry workloads which run IDHACK queries, by not doing any unnecessary work (such as ShardingState check). (see screenshot)

We should also put the serializationContext, right before the lookup call

auto serializationContext = parsedFind.findCommandRequest->getSerializationContext(); 



 Comments   
Comment by Githook User [ 17/Jan/24 ]

Author:

{'name': 'Catalin Sumanaru', 'email': 'catalin.sumanaru@mongodb.com', 'username': 'csum112'}

Message: SERVER-83625 Make `lookupQuerySettingsForFind()` not check the node's sharding recovery state (#17760)

GitOrigin-RevId: 070059e14703d2140f50fb4d3fa23770f1796c60
Branch: master
https://github.com/mongodb/mongo/commit/bb199a8460a0e301f7e21779fe2c24def4a66c48

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