[SERVER-34173] Make killOp report whether op was actually killed Created: 28/Mar/18 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Ian Boros | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | QFB | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Execution
|
| Participants: |
| Description |
|
It could be a nice improvement to have killOp report whether the op given was actually killed. Although clients couldn't use this for error checking (it's always possible for the operation to end on its own before the killOp is processed), it could be useful if someone is accidentally passing nonsense op ids. If this behavior is added, we shouldn't report failure by returning ok: 0, as this could break client code which uses a driver "runCommand" function. Instead, we should follow the pattern used by killCursors, which is to always return success, but include an additional field about whether or not the operation/cursor was actually found and killed. |
| Comments |
| Comment by Asya Kamsky [ 17/May/18 ] | |
|
Current the response is always:
| |
| Comment by Asya Kamsky [ 04/May/18 ] | |
|
I think that's an additional benefit of implementing this - having an extra opportunity to communicate to user that the operation was flagged to be killed.
| |
| Comment by Eric Milkie [ 29/Mar/18 ] | |
|
We'll have to be careful about how we message this, as the proposed feature will need to indicate whether or not there was an opid that was successfully flagged for kill, not that it actually was killed and went away synchronously. |