Summary

No spec defines how error labels should behave on an aggregate bulk-write exception (legacy BulkWriteException / ClientBulkWriteException) when that exception reports errors from multiple batches/operations with different labels. We need a spec decision on whether labels should accumulate across those errors or reflect only the most recently encountered one.

The entire error-labels model is defined once, minimally, in the transactions spec ("Any command error may include a top level errorLabels field... an array of string error labels"). Every spec that adds a label (retryable-writes, transactions, client-backpressure) only specifies when to attach that label to that single error. None addresses aggregation when several errors are reported together, which is exactly the shape of BulkWriteException/ClientBulkWriteException. Neither type's spec definition even includes a Labels/errorLabels field.

The Go driver has already faced this once for the legacy BulkWriteException, and chose to accumulate. Every batch’s labels get appended, undeduplicated, across the whole bulk write. That was also our own unilateral choice, not something the spec asked for, but it is existing, shipped Go driver behavior.

Our two candidate designs for the new ClientBulkWriteException, which disagree when batches report different labels:

1. Collect/accumulate across batches
2. Take only the most recent batch’s labels

Concretely: If batch 1 reports a write-concern error labeled RetryableWriteError and batch 2 reports one with no labels, “accumulate” keeps RetryableWriteError on the exception; “most-recent” drops it to [], silently hiding a real retryable signal from a caller inspecting the aggregate exception.

Motivation

Who is the affected end user?

Application developers using bulkWrite, and who inspect those labels to decide whether to retry.

How does this affect the end user?

Error labels exist to answer "is it safe/useful to retry, and at what scope?" RetryableWriteError drives both the driver's own automatic retry and application-level retry loops.

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

Edge case, not main path. It requires a bulk write to span multiple bulkWrite batches (large enough input) and different batches to produce errors with different label sets. Still plausible: retryable write concern errors (e.g. transient replica set state) are exactly the kind of condition that can appear on one batch and not the next.

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

The consequence is a correctness gap in the retry-signal contract.

Is this issue urgent?

No. We're raising it now because the Go driver is actively adding Labels to ClientBulkWriteException (GODRIVER-3954) and want to avoid shipping a design that has to change later for spec alignment, or diverging unnecessarily from our own legacy BulkWriteException behavior (which already accumulates, unspecified, since its original implementation).

Is this ticket required by a downstream team?

No

Is this ticket only for tests?

No. This has functional impact: it determines what Labels/errorLabels actually contains on the exception object returned to applications.

Acceptance Criteria

The spec states:

• What BulkWriteException/ClientBulkWriteException are expected to expose aggregated error labels: accumulate (union, matching how writeErrors/writeConcernErrors themselves accumulate across batches) vs. most-recent-only (matching single-operation label assignment) vs. some other aggregation rule.