[SERVER-51152] Create guardrails for parallel shells against awaiting twice Created: 24/Sep/20 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Shell, Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Raiden Worley (Inactive) | Assignee: | Backlog - Server Tooling and Methods (STM) (Inactive) |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Server Tooling & Methods
|
||||
| Participants: | |||||
| Linked BF Score: | 40 | ||||
| Story Points: | 2 | ||||
| Description |
|
Currently, startParallelShell's returned await function can be called again, and multiple calls trip an invariant because the PID is no longer registered. This is expected, but we can make the error clearer by throwing a js-side exception. We could store a variable as a property of the function, accessed through arguments.callee to determine whether the function has been called before. |
| Comments |
| Comment by Steven Vannelli [ 10/May/22 ] |
|
Moving this ticket to the Backlog and removing the "Backlog" fixVersion as per our latest policy for using fixVersions. |
| Comment by Brooke Miller [ 29/Sep/20 ] |
|
Putting this on the Backlog. If we see a related BF occur again, then we should consider scheduling it for a sprint. |