We have identified a difference in how split-prepared transaction commit and abort flows handle opCtx interruptions:

• In commit (_commitSplitPreparedTxnOnPrimary), the parent opCtx is marked uninterruptible before children are processed.

{
Take RSTL 
Mark parent optCtx uninterruptible
Call  _commitSplitPreparedTxnOnPrimary { 
    Loop on each split-txn { 
        Mark each child-optCtx uninterruptible 
        commit it. 
    }
}

• But in abort (_abortSplitPreparedTxnOnPrimary), children are aborted first (marked uninterruptible), and only after that is the parent marked uninterruptible.

{
Take RSTL 
Call  _abortSplitPreparedTxnOnPrimary { 
    Loop on each split-txn { 
        Mark each child-optCtx uninterruptible 
        abort it. 
    }

Mark parent optCtx uninterruptible
}

Given this order, it’s possible for the primary to abort some—but not all—of the split transactions if the parent opCtx is interrupted partway through the process.

Although there currently aren’t any interrupt points (such as lock acquisition or resource usage) in this section of the code, we shouldn’t implicitly depend on this. Even if it’s safe today, relying on this could be error-prone if future code changes introduce new interrupt points.