Skip to content

GODRIVER-3086 Add ErrorCodes to ServerError API #1894

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Jan 30, 2025

Conversation

prestonvasquez
Copy link
Member

GODRIVER-3086

Summary

Extend the ServerError interface to include ErrorCodes which will return a list of deduplicated error codes returned by the server during the lifetime of operation execution.

Background & Motivation

The Go Driver provides a way to check if a ServerError has a specific error code, but no way to determine all error codes that occurred during the operation.

@prestonvasquez prestonvasquez marked this pull request as draft November 15, 2024 22:29
@prestonvasquez prestonvasquez marked this pull request as ready for review November 15, 2024 22:39
@mongodb-drivers-pr-bot mongodb-drivers-pr-bot bot added the priority-3-low Low Priority PR for Review label Nov 15, 2024
Copy link
Contributor

API Change Report

./v2/mongo

compatible changes

BulkWriteException.ErrorCodes: added
CommandError.ErrorCodes: added
ServerError.ErrorCodes: added
WriteError.ErrorCodes: added
WriteException.ErrorCodes: added

Copy link
Contributor

@FGasper FGasper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for this! :)

mongo/errors.go Outdated
@@ -252,9 +252,23 @@ type ServerError interface {
// HasErrorCodeWithMessage returns true if any of the contained errors have the specified code and message.
HasErrorCodeWithMessage(int, string) bool

// ErrorCodes returns a deduplicated list of error codes returned by the
// server.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It’d be good to mention if there’s a defined sort order.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@prestonvasquez Thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I suggest:

ErrorCodes returns all error codes (unsorted) in the server’s response. This includes nested errors (e.g., write concern errors) as well as the top-level error code.

return hasErrorCode(e, code)
}

// ErrorCodes returns a list of error codes returned by the server.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It’d be good to mention if there’s a defined sort order.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ErrorCodes returns all error codes (unsorted) in the server’s response. This includes nested errors (e.g., write concern errors) as well as the top-level error code.

mongo/errors.go Outdated
}
return false

// Deduplicate error codes.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not that it affects us :), but: I see the same logic here and in WriteException’s method. This seems like the sort of thing you’d deduplicate.

matthewdale
matthewdale previously approved these changes Jan 22, 2025
Copy link
Collaborator

@matthewdale matthewdale left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! 👍

mongo/errors.go Outdated
@@ -252,9 +252,23 @@ type ServerError interface {
// HasErrorCodeWithMessage returns true if any of the contained errors have the specified code and message.
HasErrorCodeWithMessage(int, string) bool

// ErrorCodes returns a deduplicated list of error codes returned by the
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The latest revision does not deduplicate error codes.

Suggested change
// ErrorCodes returns a deduplicated list of error codes returned by the
// ErrorCodes returns a list of error codes returned by the

Copy link
Contributor

@FGasper FGasper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’ve made a few suggestions on verbiage; see what you think.

Also: are there any cases where it is, in fact, correct just to check HasErrorCode() without also checking for other, unexpected error codes? If not, should HasErrorCode()’s documentation also be updated to discourage its use?

Basically ISTM that anyplace an application calls HasErrorCode(123) should instead be a check of whether ErrorCodes()’s return contains solely 123. Is that reasonable?

mongo/errors.go Outdated
@@ -252,9 +252,23 @@ type ServerError interface {
// HasErrorCodeWithMessage returns true if any of the contained errors have the specified code and message.
HasErrorCodeWithMessage(int, string) bool

// ErrorCodes returns a deduplicated list of error codes returned by the
// server.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@prestonvasquez Thoughts?

mongo/errors.go Outdated
@@ -252,9 +252,23 @@ type ServerError interface {
// HasErrorCodeWithMessage returns true if any of the contained errors have the specified code and message.
HasErrorCodeWithMessage(int, string) bool

// ErrorCodes returns a deduplicated list of error codes returned by the
// server.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I suggest:

ErrorCodes returns all error codes (unsorted) in the server’s response. This includes nested errors (e.g., write concern errors) as well as the top-level error code.

return hasErrorCode(e, code)
}

// ErrorCodes returns a list of error codes returned by the server.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ErrorCodes returns all error codes (unsorted) in the server’s response. This includes nested errors (e.g., write concern errors) as well as the top-level error code.

@prestonvasquez
Copy link
Member Author

@FGasper

I’ve made a few suggestions on verbiage; see what you think.

I agree with the changes to the interface documentation but don't think we need to be more specific on the methods.

anyplace an application calls HasErrorCode(123) should instead be a check of whether ErrorCodes()’s return contains solely 123. Is that reasonable?

HasErrorCode's logic has not changed and so we should maintain the current intentions and usage guidelines for our users. The current documentation correctly expresses the purpose of the method for each error type.

Copy link
Contributor

@FGasper FGasper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks!

@matthewdale
Copy link
Collaborator

@FGasper I believe there are plenty of cases where HasErrorCode is sufficient, especially for single-read or single-write operations (i.e. non-bulk operations). I think it would be confusing to discourage its use.

Copy link
Collaborator

@matthewdale matthewdale left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! 👍

@FGasper
Copy link
Contributor

FGasper commented Jan 30, 2025

I’ve moved the HasErrorCode discussion to Slack.

@prestonvasquez prestonvasquez merged commit 4e0ab11 into mongodb:master Jan 30, 2025
29 of 35 checks passed
@prestonvasquez prestonvasquez deleted the GODRIVER-3086 branch January 30, 2025 16:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority-3-low Low Priority PR for Review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants