Summary

CommandFailedEvent only exposes the raw Failure error, so listeners may have to assert internal types to read server codes. Add optional error-code metadata (e.g., fields or a helper) so monitors can access code/codeName/labels without private APIs, following the existing pattern of optional event fields.

Motivation

Who is the affected end user?

Consumers of CommandFailedEvent that need to parse error codes for some reason. For example, metrics implementation for otelmongo requires providing a database status code, particularly for failures.

How does this affect the end user?

Users may have to rely on experimental behavior, as is the case with the Go Driver, or parse error codes by directly inspecting a string. The addition proposed in this ticket would make monitoring integrations simpler and more stable for this use case.

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

Unclear

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

Minor annoyance

Is this issue urgent?

No

Is this ticket required by a downstream team?

It's required by otelmongo, but is not pressing AFAIK.

Is this ticket only for tests?

No

Acceptance Criteria

• Add an optional []int32 errorCodes field. AFAICT it's not possible to get ok:0 from an operation that would also include writeErrors, but just in case and to ensure symmetry for any future expansion of CommandSucceededEvent, suggest making this type an array.
• Consider a follow-up effort for CommandSucceededEvent so write errors can expose codes as well.