SERVER-70842 Update shard split architecture guide

2 files changed, 2 insertions, 2 deletions

diff --git a/src/mongo/db/serverless/README.md b/src/mongo/db/serverless/README.md
index 24f9c10a6b9..aa077cd2877 100644
--- a/src/mongo/db/serverless/README.md
+++ b/src/mongo/db/serverless/README.md
@@ -28,7 +28,7 @@ Before proceeding with any split-specific steps, the donor must wait for all rec
     After draining, the recipient node will install the embedded recipient config. Once the config is successfully installed the recipient node will clear its <code>[lastCommittedOpTime and currentCommittedOpTime](https://github.com/mongodb/mongo/blob/646eed48d0da896588759030f2ec546ac6fbbd48/src/mongo/db/repl/replication_coordinator_impl_heartbeat.cpp#L1065-L1066)</code> and [restart oplog application](https://github.com/mongodb/mongo/blob/646eed48d0da896588759030f2ec546ac6fbbd48/src/mongo/db/repl/replication_coordinator_impl_heartbeat.cpp#L1068-L1070). We clear these two pieces of metadata to guarantee that recipient nodes never propagate opTimes from the donor timeline.
 
 5. **Accepting the split**
-    The donor [creates a ReplicaSetMonitor](https://github.com/mongodb/mongo/blob/646eed48d0da896588759030f2ec546ac6fbbd48/src/mongo/db/serverless/shard_split_donor_service.cpp#L561) at the beginning of a split operation in order to monitor recipient nodes for split acceptance. The primary criteria for split acceptance is that each recipient node reports the `recipientTagName`, however the split RSM will also [track the highest lastAppliedOpTime seen](https://github.com/mongodb/mongo/blob/646eed48d0da896588759030f2ec546ac6fbbd48/src/mongo/db/serverless/shard_split_utils.cpp#L329) for each recipient node so that we can later choose which node to elect as the recipient primary.
+    The donor [creates one SingleServerDiscoveryMonitor per recipient node](https://github.com/mongodb/mongo/blob/646eed48d0da896588759030f2ec546ac6fbbd48/src/mongo/db/serverless/shard_split_donor_service.cpp#L561) at the beginning of a split operation in order to monitor recipient nodes for split acceptance. The primary criteria for split acceptance is that each recipient node reports the `recipientTagName`, however the split monitors will also [track the highest lastAppliedOpTime seen](https://github.com/mongodb/mongo/blob/646eed48d0da896588759030f2ec546ac6fbbd48/src/mongo/db/serverless/shard_split_utils.cpp#L329) for each recipient node so that we can later choose which node to elect as the recipient primary.
 
     Once all nodes have correctly reported the recipient set name the donor will [send a replSetStepUp command](https://github.com/mongodb/mongo/blob/646eed48d0da896588759030f2ec546ac6fbbd48/src/mongo/db/serverless/shard_split_donor_service.cpp#L850) to the node with the highest `lastAppliedOpTime`, guaranteeing that the election will succeed. After sending this command the donor will [wait for a majority write](https://github.com/mongodb/mongo/blob/646eed48d0da896588759030f2ec546ac6fbbd48/src/mongo/db/serverless/shard_split_donor_service.cpp#L856) on the recipient by sending an `appendOplogNote` command with a majority write concern to the new recipient primary. We need to ensure that the new primary’s first oplog entry is majority committed otherwise it’s possible for a node with an older `lastAppliedOpTime` to become elected, and cause the chosen recipient primary to rollback before its `lastAppliedOpTime`.
 
diff --git a/src/mongo/db/serverless/serverless_operation_lock_registry.h b/src/mongo/db/serverless/serverless_operation_lock_registry.h
index d9ac07393f4..cb122d702f8 100644
--- a/src/mongo/db/serverless/serverless_operation_lock_registry.h
+++ b/src/mongo/db/serverless/serverless_operation_lock_registry.h
@@ -55,7 +55,7 @@ public:
 
     /**
      * Acquire the serverless lock for LockType and adds operationId to the set of
-     * instances tracked. Throws ConflictingOperationInProgress error if there is already an
+     * instances tracked. Throws ConflictingServerlessOperation error if there is already an
      * activeServerlessOperation in progress with a different namespace than operationNamespace.
      */
     void acquireLock(LockType lockType, const UUID& operationId);