-
Type:
Spec Change
-
Resolution: Unresolved
-
Priority:
Minor - P4
-
None
-
Component/s: CRUD & Command-Level Operations
-
None
-
Needed
-
Summary
The CRUD spec's "Top-Level Errors" section states:
When a top-level error is encountered and individual results and/or errors have already been observed, drivers MUST embed the top-level error within a BulkWriteException as the error field to retain this information.
However, no unified or prose test in the spec suite exercises this requirement for the two cases it covers:
- a top-level error after individual write errors were observed.
- a top-level error after individual results (no errors) were observed.
We found the Go driver violates both (https://jira.mongodb.org/browse/GODRIVER-4169), but the existing spec test suite caught neither. We're requesting coverage be added so this is enforced consistently rather than left to each driver to notice independently.
Motivation
Who is the affected end user?
Application developers using bulkWrite across large/multi-batch writes where a later bulkWrite batch fails outright ({ok: 0}) after an earlier batch already produced either a write error or successful results.
How does this affect the end user?
An application that inspects partialResult/writeErrors might get an incomplete or misleading picture, with no error or signal that anything is missing.
How likely is it that this problem or use case will occur?
Edge case requiring batch-splitting (large enough input to span multiple bulkWrite commands) plus a later batch failing outright. Uncommon, but it is a realistic production scenario.
If the problem does occur, what are the consequences and how severe are they?
Silent loss of diagnostic/result information the spec explicitly requires drivers to retain.
Is this issue urgent?
No.
Is this ticket required by a downstream team?
No.
Is this ticket only for tests?
Yes.
Acceptance Criteria
- A unified or prose test exists asserting that, when a bulkWrite batch fails with a write error and a subsequent batch fails with a top-level error, the resulting BulkWriteException/ClientBulkWriteException includes both the write error(s) and the top-level error (with its code/message/raw reply accessible).
- A unified or prose test exists asserting that, when a bulkWrite batch succeeds (producing observable results, no errors) and a subsequent batch fails with a top-level error, the resulting exception embeds the top-level error and partialResult reflects the results observed before the failure.
- is related to
-
GODRIVER-4169 Client.BulkWrite drops top-level errors and partial results, violating CRUD spec "Top-Level Errors"
-
- Needs Review
-
- split to
-
CDRIVER-6495 Add test coverage for top-level error handling in multi-batch bulkWrite
-
- Blocked
-
-
CSHARP-6252 Add test coverage for top-level error handling in multi-batch bulkWrite
-
- Blocked
-
-
CXX-3601 Add test coverage for top-level error handling in multi-batch bulkWrite
-
- Blocked
-
-
GODRIVER-4181 Add test coverage for top-level error handling in multi-batch bulkWrite
-
- Blocked
-
-
JAVA-6330 Add test coverage for top-level error handling in multi-batch bulkWrite
-
- Blocked
-
-
NODE-7888 Add test coverage for top-level error handling in multi-batch bulkWrite
-
- Blocked
-
-
PHPLIB-1974 Add test coverage for top-level error handling in multi-batch bulkWrite
-
- Blocked
-
-
PYTHON-6150 Add test coverage for top-level error handling in multi-batch bulkWrite
-
- Blocked
-
-
RUBY-3975 Add test coverage for top-level error handling in multi-batch bulkWrite
-
- Blocked
-
-
RUST-2520 Add test coverage for top-level error handling in multi-batch bulkWrite
-
- Blocked
-