Summary

No spec test covers a command that fails on its first and only attempt with the NoWritesPerformed error label and no RetryableWriteError label. The only existing fixture in "source/retryable-writes/tests/unified/insertOne-noWritesPerformedError.yml" uses mode: {times: 2} with errorLabels: [NoWritesPerformed, RetryableWriteError].

The retryable-writes spec requires that when all errors indicate no write was attempted, "the first error encountered must be returned," and its pseudocode enforces this with a null guard:

if (previousError == null) {
    previousError = currentError;
}

Because the server has historically bundled NoWritesPerformed with RetryableWriteError, the label only ever reached a driver on a retry attempt, after previousError was already set. An implementation that translated the pseudocode as "substitute the previous error" without the null guard passes every test in the corpus. SystemOverloadedError (client-backpressure) breaks that assumption: the server can return [SystemOverloadedError, NoWritesPerformed] with no RetryableWriteError, on the very first attempt. That error is not retryable under the retryable-writes rules, so the driver falls into the "prefer the previous error" branch with no previous error to prefer.

We need test coverage that would have caught this, plus a normative sentence so the requirement does not live only inside a pseudocode null check.

Motivation

Who is the affected end user?

Application developers issuing writes against a server that returns NoWritesPerformed without RetryableWriteError. In practice, any deployment emitting SystemOverloadedError under load.

How does this affect the end user?

On an affected driver, the failure is silent. In GODRIVER-4088, Database.RunCommand returned a nil error and handed back the server's error-response BSON as the operation result. SingleResult.Decode() succeeded on a document containing ok: 0/errmsg/code. The application proceeded as though the write had succeeded, and the real server error was unreachable. A related path, GODRIVER-4098, a failed operation was reported as "no document matched".

How likely is it that this problem or use case will occur?

It is unreachable while the server always pairs NoWritesPerformed with RetryableWriteError, and becomes reachable on the first attempt of any write when the deployment is under load with a SystemOverloadedError.

If the problem does occur, what are the consequences and how severe are they?

Silent data-correctness failure. The application believes a write succeeded (or that no document matched) when the server actually rejected the command.

Is this issue urgent?

No, but it should be covered alongside the client backpressure.

Is this ticket required by a downstream team?

No. It is of direct interest to every driver team implementing client backpressure.

Is this ticket only for tests?

Yes.

Acceptance Criteria

1. New unified fixtures covering:
   • insertOne failing on the first attempt with mode: {times: 1} and errorLabels: [SystemOverloadedError, NoWritesPerformed] expects an error with the given errorCode and errorLabelsContain: [SystemOverloadedError, NoWritesPerformed], plus an outcome asserting the collection is empty.
   • findOneAndUpdate failing on the first attempt with the same labels asserts the server error is raised rather than "no document matched". This catches the result-field class of bug that an insertOne-only fixture cannot see.
   • A write concern error variant: failCommand returning a writeConcernError carrying errorLabels: [SystemOverloadedError, NoWritesPerformed] asserts the write concern error surfaces.
   • Optionally, NoWritesPerformed with no companion label, pinning the behavior independently of backpressure.
2. "retryable-writes.md" contains an explicit normative statement near the three summary rules, e.g.: "If the only error encountered has the NoWritesPerformed label, that error MUST be returned; drivers MUST NOT substitute a null or absent previous error."