[SERVER-79959] Ensure that opCtx has been delisted before creating new opCtx during SessionWorkflow cleanup Created: 13/Aug/23 Updated: 15/Aug/23 Resolved: 15/Aug/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Blake Oler | Assignee: | Backlog - Service Architecture |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Service Arch
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 3 | ||||||||||||
| Description |
|
It is possible to get into a state where the opCtx has been killed but not yet delisted. When we try to create a new opCtx during SessionWorkflow exhaust cleanup, we assume that the client does not already have an opCtx. We had thought that this was already solved due to an earlier check to killAndDelistOperation if there existed previously an opCtx on the client. However, as part of this earlier check, we erroneously assume that the previously opCtx would have been in a healthy state. The simplest solution here is to call killAndDelistOperation regardless of whether the opCtx was already killed, so that we ensure delisting happens as well. The second kill will be essentially a no-op. |
| Comments |
| Comment by Jason Chan [ 15/Aug/23 ] |
|
marking this as a dupe of |