Summary

DRIVERS-820 modified the CRUD spec to ensure a write error's errInfo field was exposed as WriteError.details. This was necessary to make document validation errors accessible to users.

While working on DRIVERS-2385, I noticed that duplicate key errors also provide additional information, which is currently not mapped in the CRUD spec. A write error document may include keyPattern and keyValue fields at the same level where we might find errInfo for document validation. These particular fields are not essential, since the error message string does indicate the offending field and value.

When examining libmongoc and PHPC, I noticed that those fields are accessible in libmongoc since the entire bulk write result is an unmodeled BSON document; however, they become inaccessible in PHP since we use that document to construct BulkWriteException and WriteResult classes.

This seems related to DRIVERS-2385 although it would not be directly addressed by that issue, since it pertains to command errors (write errors are included in ok:1 responses). In the spirit of DRIVERS-2385, I think drivers would do well to ensure the raw write error document (and perhaps write concern error) is accessible in any WriteResult model class. Ideally, the server could be consistent about using errInfo – it may be worthwhile to suggest this as a future change, but it's unlikely we'd be able to alter behavior of existing releases.

Note that the proposed solution here to expose the entire writeError and writeConcernError document within a WriteError and WriteConcernError model class, respectively, will provide an additional implementation to satisfy DRIVERS-820.

This issue might also be addressed by the design of one-shot transactions and the new bulk API in DRIVERS-716.

Motivation

Who is the affected end user?

Users inspecting write errors.

How does this affect the end user?

Fields in server-side write and write concern errors may be inaccessible.

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

A known case is DuplicateKey(11000), which adds extra information about the offending key/value.

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

This is a minor concern for DuplicateKey(11000), since the error message includes the same information. We are not aware of other issues (noting that document validation was already addressed in DRIVERS-820).

Is this issue urgent?

No.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

No.