Alleviate problems that arise when OperationContext::markKilled is called with a non-Interruption error

XMLWordPrintableJSON

    • Server Programmability
    • Service Arch 2022-06-13, Service Arch 2022-06-27, Service Arch 2022-07-11
    • 7
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      Some places in the code rely on catching an exception in ErrorCategory::Interruption to check whether an OperationContext has been interrupted. This is a problem if any callsites ever call OperationContext::markKilled with an error code that isn't in this error category, but there's not currently anything preventing that from happening. Technically, using the Interruption category to check for OperationContext interrupt is also error prone since it's possible that other things could throw an Interruption error, so call sites which need to check for interrupt should probably catch all exceptions and then actually check the OperationContext to see if it's been interrupted.

      This ticket should either:

      • Add an invariant to markKilled to make sure all error codes passed to it belong to ErrorCategory::Interruption, and fix the broken call sites, or
      • Fix all places we catch Interruption errors and rely on that to assume the OperationContext has been interrupted to catch all DBExceptions and check the OperationContext itself for interrupt

      —

      We determined that the appropriate resolution is to remove the Interruption category. The reason being Interruption has built up a lot of cruft and has lost meaning over time. Currently, several bugs have been logged to address sections of the code base that use this category. Once those are complete, the actual removal of the category should be trivial.

            Assignee:
            Unassigned
            Reporter:
            Matthew Saltz (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated: