[SERVER-51451] Flaky mongos API version parameter tests Created: 09/Oct/20 Updated: 29/Oct/23 Resolved: 19/Oct/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 5.0.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | A. Jesse Jiryu Davis | Assignee: | A. Jesse Jiryu Davis |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Sprint: | Repl 2020-10-19, Repl 2020-11-02 | ||||
| Participants: | |||||
| Linked BF Score: | 23 | ||||
| Description |
|
Two kinds of failures. First, an intermittent failure in api_params_nontransaction_sharded.js. On a 2-shard cluster with shard 0 and shard 1, the test does a "find" on mongos with $where: sleep(99999) and waits for the "find" command to appear in currentOp. Sometimes it times out without seeing the command in currentOp. Second, an intermittent failure in api_params_nontransaction_unsharded.js and api_params_nontransaction_sharded.js. The test executes "find" with batchSize 1, and receives a cursorId in the "find" reply. The test executes the "killCursors" command with that cursorId, then searches for a "killCursors" command in the shard 0 primary's log, but doesn't find it. I'm still diagnosing both failures. |
| Comments |
| Comment by Githook User [ 19/Oct/20 ] |
|
Author: {'name': 'A. Jesse Jiryu Davis', 'email': 'jesse@mongodb.com', 'username': 'ajdavis'}Message: |
| Comment by A. Jesse Jiryu Davis [ 18/Oct/20 ] |
|
Reopening, there's been a new failure of the first kind, a failure while waiting to see "find" in "currentOp". Since I've added more logging to the test I can see clearly the cause of the error: while the test is looking for one "find" command with a certain "comment" value in "currentOp", it sees two of them, one for each shard. It asserts that the number of "find" commands it sees is < 2, and fails. In my previous fix I thought I'd avoided this possibility by adding a filter on the shard key in "find", but apparently mongos has targeted both shards anyway. |
| Comment by Githook User [ 14/Oct/20 ] |
|
Author: {'name': 'A. Jesse Jiryu Davis', 'email': 'jesse@mongodb.com', 'username': 'ajdavis'}Message: |