[SERVER-48506] Throw MaxTimeMSExpired instead of FailedToSatisfyReadPreference when RSM deadline is less than max Created: 29/May/20 Updated: 29/Oct/23 Resolved: 09/Jul/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.4.1, 4.7.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Haley Connelly | Assignee: | Janna Golden |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Backport Requested: |
v4.4
|
||||||||
| Sprint: | Sharding 2020-07-13, Sharding 2020-06-29 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 16 | ||||||||
| Description |
|
In server_status_with_timeout_cursors.js, maxTimeMS is set small enough so that it's likely the cursor will time out over its lifetime. It executes find() operations that are expected to fail due to maxTimeMS timeout. We should change RemoteCommandTargeterRs so that it throws MaxTimeMsExpired rather than FailedToSatisfyReadPreference if the remaining maxTimeMs is less than the RSM deadline to find a host to expose a more accurate error to the user. |
| Comments |
| Comment by Githook User [ 04/Aug/20 ] |
|
Author: {'name': 'jannaerin', 'email': 'golden.janna@gmail.com', 'username': 'jannaerin'}Message: (cherry picked from commit c8e9a31cd3c21b7b40864e39323fbf0823f79f61) |
| Comment by Githook User [ 09/Jul/20 ] |
|
Author: {'name': 'jannaerin', 'email': 'golden.janna@gmail.com', 'username': 'jannaerin'}Message: |
| Comment by James Wahlin [ 15/Jun/20 ] |
|
The error code added under |
| Comment by Janna Golden [ 11/Jun/20 ] |
|
I didn't realize when Haley and I had discussed possible solutions that it was not possible to pass parameters at startup for an individual test in our concurrency suites - we can only do so in the suite's yml file. This would mean we would have to override the RSM default refresh period to < 10ms for every suite that this test runs in, which I don't think we want to do (we'll spam servers with too many isMaster responses). The failpoint mentioned needs to be set at startup when the client starts up its RSM. james.wahlin, it looks like you had added another acceptable error code as a part of |
| Comment by Haley Connelly [ 29/May/20 ] |
|
One possible solution is to use the failpoint modifyReplicaSetMonitorDefaultRefreshPeriod to override the isMaster frequency for this test. Possible scenario: Meanwhile, with the small maxTimeMS and the RSM thinking there is no primary for the replica set, no host can be found in time for the next query and the RSM reports failedToSatisfyReadPreference. |