Skip to content
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

Standardize the error codes from API endpoints #317

Merged
merged 8 commits into from
Mar 6, 2024

Conversation

jianoaix
Copy link
Contributor

@jianoaix jianoaix commented Mar 5, 2024

Why are these changes needed?

Standardize the error codes to make it easier to understand, communicate, account and for better UX.

Checks

  • I've made sure the lint is passing in this PR.
  • I've made sure the tests are passing. Note that there might be a few flaky tests, in that case, please comment that they are not relevant.
  • Testing Strategy
    • Unit tests
    • Integration tests
    • This PR is not tested :(

common/errors.go Outdated
@@ -0,0 +1,39 @@
package common
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should this just go in the api package?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point! The only question is api is currently all protobuf stuff, it otherwise fits better in api since these are all around APIs. I'll move it over unless other folks have different thought/suggestion.

Copy link
Contributor

@dmanc dmanc left a comment

Choose a reason for hiding this comment

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

This is great! Are we going to modify the metrics based on these error codes in a separate PR?

@@ -93,12 +93,12 @@ func (s *DispersalServer) DisperseBlobAuthenticated(stream pb.Disperser_Disperse
// Process disperse_request
in, err := stream.Recv()
if err != nil {
return fmt.Errorf("error receiving next message: %v", err)
return common.NewInvalidArgError(fmt.Sprintf("error receiving next message: %v", err))
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: Is this really due to invalid argument? Feel like stream.Revc() breaking could be due to pod dying in the middle or something like that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

good point, this may be not a clear cut whether it's client side or server side issue, as it may be caused by various reasons, like network connection, malformed message as well as server side resource issue etc.
I think overall it may fit better as client-side, as this is still at the gate of the system at this point.

}

s.logger.Debug("metadataKey", "metadataKey", metadataKey.String())
metadata, err := s.blobStore.GetBlobMetadata(ctx, metadataKey)
if err != nil {
return nil, err
// TODO: we need to distinguish NOT_FOUND from actual internal error.
Copy link
Contributor

Choose a reason for hiding this comment

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

Would probably need to standarize the error message and then check that here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep, we could check the message, or surface an error with NewNotFoundError inside the GetBlobMetaata (this approach was used in the Churner, L95 in churner/server.go)

common/errors.go Outdated
"google.golang.org/grpc/status"
)

// The canonical errors from the EigenDA gRPC API endpoints.
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need one for timeout?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We may add if it's becoming a more clear case to cover

@jianoaix
Copy link
Contributor Author

jianoaix commented Mar 6, 2024

This is great! Are we going to modify the metrics based on these error codes in a separate PR?

Yep, I'll follow up to revamp the metrics to use these codes.

@jianoaix jianoaix merged commit b2e47d2 into Layr-Labs:master Mar 6, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants