DRIVERS-2091: remove references to getLastError

source/read-write-concern/read-write-concern.md

@@ -298,19 +298,6 @@ writeConcern = { w: 0, wtimeoutMS: 100 }; // Unacknowledged
 
 #### On the Wire
 
-##### OP_INSERT, OP_DELETE, OP_UPDATE
-
-`WriteConcern` is implemented by sending the `getLastError` (GLE) command directly after the operation. Drivers SHOULD
-piggy-back the GLE onto the same buffer as the operation. Regardless, GLE MUST be sent on the same connection as the
-initial write operation.
-
-When a user has not specified a `WriteConcern` or has specified the server's default `WriteConcern`, drivers MUST send
-the GLE command without arguments. For example: `{ getLastError: 1 }`
-
-Drivers MUST NOT send a GLE for an `Unacknowledged WriteConcern`. In this instance, the server will not send a reply.
-
-See the `getLastError` command documentation for other formatting.
-
 ##### Write Commands
 
 The `insert`, `delete`, and `update` commands take a named parameter, `writeConcern`. See the command documentation for
@@ -523,11 +510,7 @@ Below are English descriptions of other items that should be tested:
 ### WriteConcern
 
 1. Commands supporting a write concern MUST NOT send the default write concern to the server.
-2. Commands supporting a write concern MUST send any non-default acknowledged write concern to the server, either in the
-    command or as a getLastError.
-3. On ServerVersion less than 2.6, drivers MUST NOT send a getLastError command for an Unacknowledged write concern.
-4. FindAndModify helper methods MUST NOT send a write concern when the MaxWireVersion is less than 4.
-5. Helper methods for other commands that write MUST NOT send a write concern when the MaxWireVersion is less than 5.
+2. Commands supporting a write concern MUST send any non-default write concern to the server in the command.
 
 ## Reference Implementation
 
@@ -550,8 +533,6 @@ instance, we send it.
 
 ## Changelog
 
-- 2024-08-23: Migrated from reStructuredText to Markdown.
-
 - 2015-10-16: ReadConcern of local is no longer allowed to be used when talking with MaxWireVersion \< 4.
 
 - 2016-05-20: Added note about helpers for commands that write accepting a writeConcern parameter.
@@ -593,6 +574,10 @@ instance, we send it.
 
 - 2022-10-05: Remove spec front matter and reformat changelog.
 
+- 2024-08-23: Migrated from reStructuredText to Markdown.
+
+- 2024-10-30: Remove reference to getLastError
+
 [^1]: This is only possible in a sharded cluster. When a write is routed to multiple shards and more than one shard
     returns a writeConcernError, then mongos will construct a new writeConcernError with the "WriteConcernFailed" error
     code and an errmsg field contains the stringified writeConcernError from each shard. Note that each shard may return

source/server-discovery-and-monitoring/server-discovery-and-monitoring-tests.md

@@ -53,18 +53,6 @@ ServerDescription's error field.
 
 Clients MUST NOT depend on any particular field order in these responses.
 
-### getLastError
-
-GLE response after OP_INSERT on an arbiter, secondary, recovering member, or ghost:
-
-> {ok: 1, err: "not writable primary"}
-
-[Possible GLE response in MongoDB 2.6](https://jira.mongodb.org/browse/SERVER-9617) during failover:
-
-> {ok: 1, err: "replicatedToNum called but not master anymore"}
-
-Note that this error message contains "not master" but does not start with it.
-
 ### Write command
 
 Response to an "insert" command on an arbiter, secondary, recovering member, or ghost:

source/server-discovery-and-monitoring/server-discovery-and-monitoring.md

@@ -1109,7 +1109,7 @@ def parseGle(response):
     if "err" in response:
         handleError(CommandError(response, response["err"], response["code"]))
 
-# Parse response to any command besides getLastError.
+# Parse response to any command
 def parseCommandResponse(response):
     if not response["ok"]:
         handleError(CommandError(response, response["errmsg"], response["code"]))
@@ -1169,8 +1169,8 @@ operation needs the server sooner than that, then a re-check will be triggered b
 
 ##### "not writable primary" and "node is recovering"
 
-These errors are detected from a getLastError response, write command response, or query response. Clients MUST check if
-the server error is a "node is recovering" error or a "not writable primary" error.
+These errors are detected from a write command response or query response. Clients MUST check if the server error is a
+"node is recovering" error or a "not writable primary" error.
 
 If the response includes an error code, it MUST be solely used to determine if error is a "node is recovering" or "not
 writable primary" error. Clients MUST match the errors by the numeric error code and not by the code name, as the code
@@ -1921,6 +1921,8 @@ oversaw the specification process.
 
 ## Changelog
 
+- 2024-11-11: Removed references to `getLastError`
+
 - 2024-11-04: Make the description of `TopologyDescription.servers` consistent with the spec tests.
 
 - 2024-08-16: Updated host b wire versions in `too_new` and `too_old` tests

source/server_write_commands/server_write_commands.md

@@ -484,10 +484,13 @@ It must convert that request into write operations + gle's and use the old op co
 
 ### Are we discontinuing the use of getLastError?
 
-Yes but as of 2.6 the existing getLastError behavior is supported for backward compatibility.
+Yes but as of 2.6 the existing getLastError behavior is supported for backward compatibility. Note also that
+`getLastError` was removed in server version 5.1.
 
 ## Changelog
 
+- 2024-11-11: Add note that getLastError has been removed from the server.
+
 - 2024-07-31: Migrated from reStructuredText to Markdown.
 
 - 2024-06-04: Add FAQ entry outlining client-side `_id` value generation Update FAQ to indicate legacy opcodes were