[SERVER-46162] Race in OplogFetcherAutoReconnectsButFails Created: 14/Feb/20 Updated: 29/Oct/23 Resolved: 14/Feb/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.4 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Lingzhi Deng | Assignee: | Lingzhi Deng |
| 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-02-24 | ||||
| Participants: | |||||
| Linked BF Score: | 0 | ||||
| Description |
|
In test OplogFetcherAutoReconnectsButFails, the intention was to simulate a disconnect while the oplog fetcher is waiting for a response from the first find command and shut down the remote server before the oplog fetcher retries to connect. However, if _mockServer->shutdown() runs too fast, it could fail the initial connection as well, which is not what this test was intended for. Instead, we should use simulateNetworkDisconnect to simulate a disconnect then use the hangBeforeOplogFetcherRetries failpoint to hang the retry and shut down the remote server before the oplog fetcher retries. |
| Comments |
| Comment by Githook User [ 14/Feb/20 ] |
|
Author: {'name': 'Lingzhi Deng', 'username': 'ldennis', 'email': 'lingzhi.deng@mongodb.com'}Message: |