ReadyRangeDeletionsProcessor runs each deletion batch on a dedicated alternate client ("range-deleter-batch") whose OperationContext is a CancelableOperationContext created from HierarchicalCancelableOperationContextFactory:

That batch opCtx is killed on cancellation via an executor-scheduled continuation.

On stepdown, RangeDeleterService::_stopService shuts the executor down before calling ReadyRangeDeletionsProcessor::shutdown(). When the parent cancellation token subsequently fires, the .thenRunOn(_executor) continuation runs with a cancelled status, so the markKilled body is skipped and the batch opCtx is never interrupted.

If a deletion batch is blocked mid-flight due to some reason when the stepdown lands the range-deleter thread never returns. Consequences cascade:

• ~ReadyRangeDeletionsProcessor's _thread.join() blocks forever and the next stepUp's (of same primary that stepped down)
• RangeDeleterService::_joinAndResetState blocks.
• onStepUpComplete never finishes; the node never completes its transition to primary.