[SERVER-38175] Invariant on error codes with ErrorExtraInfo for OperationContext markKilled() and timeout Created: 16/Nov/18 Updated: 08/Jan/24 Resolved: 06/Mar/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 4.1.5 |
| Fix Version/s: | 4.1.9 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | James Wahlin | Assignee: | Mira Carey |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Sprint: | Service Arch 2018-12-31, Service Arch 2019-01-14, Service Arch 2019-01-28, Service Arch 2019-02-11, Service Arch 2019-02-25, Service Arch 2019-03-11 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
The OperationContext class accepts an ErrorCodes::Error for markKilled() and deadline-setting methods. This error code may be converted to a Status object on checkForInterruptNoAssert() or waitForConditionOrInterruptNoAssertUntil() call. When the error code is one that is associated with an ErrorExtraInfo object, Status construction will fail as we expect Status construction to either include a subclass of ErrorExtraInfo or a BSONObj from which it can be serialized. Until a use case comes up, add an invariant to prevent passing an error code with extra info |
| Comments |
| Comment by Githook User [ 06/Mar/19 ] |
|
Author: {'name': 'Jason Carey', 'username': 'hanumantmk', 'email': 'jcarey@argv.me'}Message: The OperationContext class accepts an ErrorCodes::Error for markKilled() Until a use case comes up, add an invariant to prevent passing an error |
| Comment by James Wahlin [ 28/Feb/19 ] |
|
mira.carey@mongodb.com - while working on |
| Comment by Mira Carey [ 27/Feb/19 ] |
|
james.wahlin, do you have a use case where you'd like to kill an op with an extra info status? Or is this pointing out that if you do (kill with a code), that checkForInterrupt calls with fassert / throw a special exception afterwards? If the latter, I might be inclined to solve the problem by invariant'ing coming in, rather than making the machinery more flexible (as I'm not sure it's actually a good idea to use the opCtx kill machinery with non-interruption codes) |