NoWritesPerformed and retryable batch outcome ambiguity
Parent: Retryable Writes · Published reference · snapshot 2026-10-27
↓ Facts as markdownall context files
Source-anchored research for NoWritesPerformed and retryable batch outcome ambiguity. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Problems, failure modes and limitations
- MongoDB documents NoWritesPerformed starting in version 6.1: when both attempts fail without any write, the label distinguishes zero work from partial insertMany execution; earlier versions lacked this distinction. (high confidence) [source]
- The retryable-writes specification selects the latest error indicating a write attempt when any such error exists, but the first error when all attempts are known no-ops. Thus a later NoWritesPerformed error must not replace an earlier ambiguous write error. (high confidence) (verified as of 2026-01-14) [source]
- Retryable execution is command-scoped: drivers assign separate transaction numbers to split write commands and reuse each command's transaction ID on retry. A zero-write failure for a later command therefore does not establish zero writes across the whole application bulk. (medium confidence) [source]
- A failed retry stops remaining split-batch execution even when ordered is false. Drivers are encouraged to expose intermediary results; client-level BulkWriteException defines optional partialResult for confirmed successes before the error. (high confidence) [source]
- DRIVERS-2501 records an earlier all-NoWritesPerformed error sequence that could propagate null; the documented correction retains the first labeled error. The specification likewise initializes its saved error on the first failure. (high confidence) [source]
- Retryability is evaluated per command after batch splitting. If a retry fails, remaining operations stop even for unordered batches. Therefore a no-write result for the failed command cannot by itself establish zero effects across earlier commands in the logical batch. (medium confidence) [source]
Comparisons and alternatives
- The Node.js driver's October 2022 NODE-4503 change explicitly throws the original error when a retry error carries NoWritesPerformed, providing an implementation example of preserving the earlier failure rather than reporting only the later no-op. (medium confidence) [source]
Facts and statements
- A missing acknowledgment can leave a write's outcome unknown. Application-level replay of non-idempotent work can duplicate effects; a failed response alone is not proof of non-execution. (high confidence) [source]
- A missing acknowledgement can leave a write successful but unknown to the client. Consequently, absence of NoWritesPerformed is not proof that a particular number of documents was inserted; the manual’s partial-work example must not be read as a universal converse. (high confidence) [source]
- MongoClient.bulkWrite exceptions distinguish top-level errors, write-concern errors, individual write errors, and optional partialResult. Drivers must omit partialResult unless at least one successful write can be established; omission therefore does not prove that no write occurred. (low confidence) [source]
- Definite non-execution and unknown execution require different recovery decisions. Repeating a non-idempotent operation after an unknown outcome can duplicate effects; MongoDB retryable writes address this with shared operation identity between driver and server. (high confidence) [source]
Children
- No children recorded.