Clean up startTransaction handling for transaction API in client transaction case

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Fixed
    • Priority: Major - P3
    • 6.0.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Fully Compatible
    • Sharding 2022-03-07
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      Currently, the transaction API will never inject `startTransaction:true` or other "first transaction command" options (e.g. read/write concern) into a command in its client execution context. This works when the API is used by commands that aren't the first in their transaction, but is inconvenient when the command sent by the API actually will be the first sent for its client transaction, since the caller would need to manually include the start transaction options. Instead the API should infer this context based on the result of isStartingMultiDocumentTransaction() / isContinuingMultiDocumentTransaction() from the callers opCtx.

      Additionally, we should add full unit test coverage for all logic branches in the API for the client transaction case, to supplement the integration coverage from SERVER-59186.

            Assignee:
            Jack Mulrow
            Reporter:
            Jack Mulrow
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: