If setUserWriteBlockMode changes a primary's user write block mode, it will issue a write to a system collection. If the primary's user write block mode disposition is unchanged, then the command is a no-op and no write is issued. Either way, the command doesn't know whether the rest of the replicaset agrees with the local state yet, and so will await majority confirmation of the active Client object's last written OpTime.

Unfortunately, the no-op variant of the command does not advance the OpTime. If an election occurs after the OpTime is stored in the Client but before commit is awaited, waiting will fail with an error. It will not be possible to re-run the command on the same connection, because the OpTime is never advanced.

Instead, if we find that we're eliding writes, we should advance the Client's OpTime using setLastOpToSystemLastOpTime