[SERVER-81877] ShardRemote::_scheduleCommand can update RPC timeout to use OpCtx timeout but doesn't update error code Created: 04/Oct/23 Updated: 12/Dec/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | George Wangensteen | Assignee: | Backlog - Cluster Scalability |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | cs-subteam1, sharding-nyc-subteam1 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Cluster Scalability
|
||||||||
| Participants: | |||||||||
| Story Points: | 3 | ||||||||
| Description |
|
ShardRemote::_scheduleCommand will update the timeout of the RemoteCommandRequest for RPCs it manages based on the remaining time left for the OperationContext the command is associated with see here However, it doesn't update the timeout code that the RemoteCommandRequest uses by default see here to indicate timeout errors. As a result, if this timeout is hit, the networking layer will throw NetworkInterfaceExceededTimeLimit (the default RCR/networking timeout error), instead of maxTimeMSExpired, even if the timeout came from the maxTimeMS associated with the opCtx. The function should either conditionally also update the timeoutCode for the RCR or rewrite any errors manually. |