[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:
Depends
is depended on by SERVER-37124 Retry full upsert path when duplicate... Closed
Related
is related to SERVER-38038 mongo shell should be linked with Err... Closed
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: SERVER-38175 invariant on markKill w extra info

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
Branch: master
https://github.com/mongodb/mongo/commit/39b7722f44e2124ad46c19f95d4059985e7d4132

Comment by James Wahlin [ 28/Feb/19 ]

mira.carey@mongodb.com - while working on SERVER-37124 and making DuplicateKey an error with an ErrorExtraInfo object I encountered this failure. I believe it was on checkForInterruptNoAssert() call. It turned out that the path setting DuplicateKey was doing so for an error that was not actually a DuplicateKey scenario, so I addressed by changing the error code. Given that, I think it is fine to invariant on entry. We can always adjust later if a use case arises that calls for it.

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)

Generated at Thu Feb 08 04:48:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.