[SERVER-74339] Race condition in shard_split_startup_recovery_aborted.js with abort timeout Created: 23/Feb/23 Updated: 29/Oct/23 Resolved: 03/Apr/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.0.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Christopher Caplinger | Assignee: | Christopher Caplinger |
| 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: | Server Serverless 2023-03-06, Server Serverless 2023-03-20, Server Serverless 2023-04-03, Server Serverless 2023-04-17 | ||||
| Participants: | |||||
| Linked BF Score: | 5 | ||||
| Description |
|
there is a race condition between setting up the timer and waiting for the failpoint. if the timer elapses before getting to the continuation where we wait for the failpoint, we'll just end up waiting forever. we could increase the timeout to make this less likely, but this will (a) slow down the test, and (b) not necessarily prevent this from happening in the future. perhaps an existing (or new) failpoint can be utilized, or some other means of testing the correct abort behavior without explicitly relying on a timeout. |
| Comments |
| Comment by Githook User [ 03/Apr/23 ] |
|
Author: {'name': 'Christopher Caplinger', 'email': 'christopher.caplinger@mongodb.com', 'username': 'UnicodeSnowman'}Message: |
| Comment by Christopher Caplinger [ 03/Apr/23 ] |
|
matt.broadstone@mongodb.com had previously expressed interest in reviewing it at a triage meeting awhile back. happy to merge it if he's okay with the changes. |
| Comment by Didier Nadeau [ 03/Apr/23 ] |
|
christopher.caplinger@mongodb.com I see this PR has been open for a while. Can we merge it quickly to resolve the BF ? |