feat: implement custom error types for DA #115
Conversation
Introduced multiple custom error types for the DA package. Because of JSON-RPC library used, each error has to be it's own type (can't use sentinel values). gRPC on the other hand doesn't support wrapping typed errors, and codes are "standardized" (currently only "Not Found" used).
|
Warning Rate limit exceeded@tzdybal has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 9 minutes and 33 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. WalkthroughThe changes introduce a comprehensive error handling mechanism across multiple files, focusing on JSON-RPC and gRPC protocols. A new file Changes
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
I'll try to define protobuf for error (code/enum) and use |
Implemented detailed gRPC error handling by defining custom error types and appropriate error codes for better differentiation in the DA package. Each error type now provides a gRPC status with granular error details using the newly introduced error codes.
Introduced a new error code and corresponding error type for when a requested height is from the future. Updated functions to handle this new type and included its gRPC status representation.
Previously, only `Get` method supported proper error mapping.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
🧹 Outside diff range and nitpick comments (8)
proxy/jsonrpc/errors.go (1)
11-21: Consider ordering error registrations for improved readability.The current order of error registrations doesn't follow a clear pattern. Consider ordering them alphabetically by error code or grouping them by related functionality. This would improve readability and make it easier to maintain the list in the future.
Here's an example of alphabetical ordering:
errs := jsonrpc.NewErrors() errs.Register(jsonrpc.ErrorCode(da.CodeBlobNotFound), new(*da.ErrBlobNotFound)) errs.Register(jsonrpc.ErrorCode(da.CodeBlobSizeOverLimit), new(*da.ErrBlobSizeOverLimit)) errs.Register(jsonrpc.ErrorCode(da.CodeContextDeadline), new(*da.ErrContextDeadline)) errs.Register(jsonrpc.ErrorCode(da.CodeFutureHeight), new(*da.ErrFutureHeight)) errs.Register(jsonrpc.ErrorCode(da.CodeTxAlreadyInMempool), new(*da.ErrTxAlreadyInMempool)) errs.Register(jsonrpc.ErrorCode(da.CodeTxIncorrectAccountSequence), new(*da.ErrTxIncorrectAccountSequence)) errs.Register(jsonrpc.ErrorCode(da.CodeTxTimedOut), new(*da.ErrTxTimedOut)) errs.Register(jsonrpc.ErrorCode(da.CodeTxTooLarge), new(*da.ErrTxTooLarge))proto/da/da.proto (1)
133-148: Add documentation for new error handling elementsThe new
ErrorCodeenum andErrorDetailsmessage are well-integrated into the existing proto file. To further improve the documentation, consider adding comments explaining their purpose and usage.Here's a suggested addition:
// ErrorCode defines specific error scenarios that can occur in the DA service. // Codes in the 32xxx range are reserved for custom DA-specific errors. enum ErrorCode { // ... (enum values as previously suggested) } // ErrorDetails encapsulates error information to be included in gRPC responses. message ErrorDetails { ErrorCode code = 1; }These comments provide context for developers who will be working with these new elements.
🧰 Tools
🪛 buf
135-135: Enum value name "Unknown" should be prefixed with "ERROR_CODE_".
(ENUM_VALUE_PREFIX)
135-135: Enum value name "Unknown" should be UPPER_SNAKE_CASE, such as "UNKNOWN".
(ENUM_VALUE_UPPER_SNAKE_CASE)
135-135: Enum zero value name "Unknown" should be suffixed with "_UNSPECIFIED".
(ENUM_ZERO_VALUE_SUFFIX)
136-136: Enum value name "BlobNotFound" should be prefixed with "ERROR_CODE_".
(ENUM_VALUE_PREFIX)
136-136: Enum value name "BlobNotFound" should be UPPER_SNAKE_CASE, such as "BLOB_NOT_FOUND".
(ENUM_VALUE_UPPER_SNAKE_CASE)
137-137: Enum value name "BlobSizeOverLimit" should be prefixed with "ERROR_CODE_".
(ENUM_VALUE_PREFIX)
137-137: Enum value name "BlobSizeOverLimit" should be UPPER_SNAKE_CASE, such as "BLOB_SIZE_OVER_LIMIT".
(ENUM_VALUE_UPPER_SNAKE_CASE)
138-138: Enum value name "TxTimedOut" should be prefixed with "ERROR_CODE_".
(ENUM_VALUE_PREFIX)
138-138: Enum value name "TxTimedOut" should be UPPER_SNAKE_CASE, such as "TX_TIMED_OUT".
(ENUM_VALUE_UPPER_SNAKE_CASE)
139-139: Enum value name "TxAlreadyInMempool" should be prefixed with "ERROR_CODE_".
(ENUM_VALUE_PREFIX)
139-139: Enum value name "TxAlreadyInMempool" should be UPPER_SNAKE_CASE, such as "TX_ALREADY_IN_MEMPOOL".
(ENUM_VALUE_UPPER_SNAKE_CASE)
140-140: Enum value name "TxIncorrectAccountSequence" should be prefixed with "ERROR_CODE_".
(ENUM_VALUE_PREFIX)
140-140: Enum value name "TxIncorrectAccountSequence" should be UPPER_SNAKE_CASE, such as "TX_INCORRECT_ACCOUNT_SEQUENCE".
(ENUM_VALUE_UPPER_SNAKE_CASE)
141-141: Enum value name "TxTooLarge" should be prefixed with "ERROR_CODE_".
(ENUM_VALUE_PREFIX)
141-141: Enum value name "TxTooLarge" should be UPPER_SNAKE_CASE, such as "TX_TOO_LARGE".
(ENUM_VALUE_UPPER_SNAKE_CASE)
142-142: Enum value name "ContextDeadline" should be prefixed with "ERROR_CODE_".
(ENUM_VALUE_PREFIX)
142-142: Enum value name "ContextDeadline" should be UPPER_SNAKE_CASE, such as "CONTEXT_DEADLINE".
(ENUM_VALUE_UPPER_SNAKE_CASE)
143-143: Enum value name "FutureHeight" should be prefixed with "ERROR_CODE_".
(ENUM_VALUE_PREFIX)
143-143: Enum value name "FutureHeight" should be UPPER_SNAKE_CASE, such as "FUTURE_HEIGHT".
(ENUM_VALUE_UPPER_SNAKE_CASE)
test/test_suite.go (2)
144-144: Improved error assertion in ConcurrentReadWriteTestThe change enhances the error assertion by using
assert.ErrorIsto check for the specificda.ErrFutureHeighterror type. This is a good improvement that aligns with the PR's objective of using custom error types.For consistency, consider updating the error variable name from
errto a more descriptive name, such aserrFutureHeight. This would make the code even more readable:errFutureHeight := d.GetIDs(ctx, i, []byte{}) if errFutureHeight != nil { assert.ErrorIs(t, errFutureHeight, &da.ErrFutureHeight{}) }
165-165: Improved error assertion in HeightFromFutureTestThe change enhances the error assertion by using
assert.ErrorIsto check for the specificda.ErrFutureHeighterror type. This improvement aligns well with the PR's objective of using custom error types and improving error handling.For consistency with other tests and to provide more context, consider adding an error message to the assertion:
assert.ErrorIs(t, err, &da.ErrFutureHeight{}, "Expected ErrFutureHeight when querying a future height")This addition would make the test output more informative if the assertion fails.
proxy/grpc/client.go (1)
Line range hint
1-163: Summary: Consistent error handling improvements with areas for verification.The changes in this file consistently apply
tryToMapErrorto standardize error handling across client methods, aligning with the PR objective. This approach enhances error management and potentially allows for more structured error responses.Points to verify:
- The implementation of
tryToMapErrorand its impact on error types returned to callers.- The slightly different error return pattern in the
Validatemethod and its handling by callers.- Ensure that these changes do not break existing error handling in the codebase that depends on these client methods.
Consider documenting the new error handling approach, including the purpose and behavior of
tryToMapError, to maintain clarity for future development and debugging.proxy/grpc/errors.go (2)
51-52: Provide more informative error messages in the default case.In the default case of the
errorForCodefunction, the returned error message is "unknown error code". Including the actual error code in the message can aid in debugging and provide clearer context.Apply this diff to enhance the error message:
default: - return errors.New("unknown error code") + return fmt.Errorf("unknown error code: %v", code) }Remember to import the
fmtpackage if it's not already included:import ( "errors" + "fmt"
3-10: Optimize import statements by grouping and ordering.For improved readability and maintenance, group standard library imports separately from third-party imports and order them alphabetically within their groups.
Apply this diff to reorganize the imports:
import ( - "errors" - - "google.golang.org/grpc/status" - "errors" + "fmt" + "google.golang.org/grpc/status" + "github.com/rollkit/go-da" pbda "github.com/rollkit/go-da/types/pb/da" )errors.go (1)
69-69: Grammar Correction: Adjust wording in the commentTo improve clarity, change "when context deadline exceeds" to "when the context deadline is exceeded".
Apply this diff:
-// ErrContextDeadline is the error message returned by the DA when context deadline exceeds. +// ErrContextDeadline is the error message returned by the DA when the context deadline is exceeded.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
types/pb/da/da.pb.gois excluded by!**/*.pb.go
📒 Files selected for processing (9)
- errors.go (1 hunks)
- proto/da/da.proto (1 hunks)
- proxy/grpc/client.go (7 hunks)
- proxy/grpc/errors.go (1 hunks)
- proxy/jsonrpc/client.go (1 hunks)
- proxy/jsonrpc/errors.go (1 hunks)
- proxy/jsonrpc/server.go (1 hunks)
- test/dummy.go (2 hunks)
- test/test_suite.go (3 hunks)
🧰 Additional context used
🪛 buf
proto/da/da.proto
135-135: Enum value name "Unknown" should be prefixed with "ERROR_CODE_".
(ENUM_VALUE_PREFIX)
135-135: Enum value name "Unknown" should be UPPER_SNAKE_CASE, such as "UNKNOWN".
(ENUM_VALUE_UPPER_SNAKE_CASE)
135-135: Enum zero value name "Unknown" should be suffixed with "_UNSPECIFIED".
(ENUM_ZERO_VALUE_SUFFIX)
136-136: Enum value name "BlobNotFound" should be prefixed with "ERROR_CODE_".
(ENUM_VALUE_PREFIX)
136-136: Enum value name "BlobNotFound" should be UPPER_SNAKE_CASE, such as "BLOB_NOT_FOUND".
(ENUM_VALUE_UPPER_SNAKE_CASE)
137-137: Enum value name "BlobSizeOverLimit" should be prefixed with "ERROR_CODE_".
(ENUM_VALUE_PREFIX)
137-137: Enum value name "BlobSizeOverLimit" should be UPPER_SNAKE_CASE, such as "BLOB_SIZE_OVER_LIMIT".
(ENUM_VALUE_UPPER_SNAKE_CASE)
138-138: Enum value name "TxTimedOut" should be prefixed with "ERROR_CODE_".
(ENUM_VALUE_PREFIX)
138-138: Enum value name "TxTimedOut" should be UPPER_SNAKE_CASE, such as "TX_TIMED_OUT".
(ENUM_VALUE_UPPER_SNAKE_CASE)
139-139: Enum value name "TxAlreadyInMempool" should be prefixed with "ERROR_CODE_".
(ENUM_VALUE_PREFIX)
139-139: Enum value name "TxAlreadyInMempool" should be UPPER_SNAKE_CASE, such as "TX_ALREADY_IN_MEMPOOL".
(ENUM_VALUE_UPPER_SNAKE_CASE)
140-140: Enum value name "TxIncorrectAccountSequence" should be prefixed with "ERROR_CODE_".
(ENUM_VALUE_PREFIX)
140-140: Enum value name "TxIncorrectAccountSequence" should be UPPER_SNAKE_CASE, such as "TX_INCORRECT_ACCOUNT_SEQUENCE".
(ENUM_VALUE_UPPER_SNAKE_CASE)
141-141: Enum value name "TxTooLarge" should be prefixed with "ERROR_CODE_".
(ENUM_VALUE_PREFIX)
141-141: Enum value name "TxTooLarge" should be UPPER_SNAKE_CASE, such as "TX_TOO_LARGE".
(ENUM_VALUE_UPPER_SNAKE_CASE)
142-142: Enum value name "ContextDeadline" should be prefixed with "ERROR_CODE_".
(ENUM_VALUE_PREFIX)
142-142: Enum value name "ContextDeadline" should be UPPER_SNAKE_CASE, such as "CONTEXT_DEADLINE".
(ENUM_VALUE_UPPER_SNAKE_CASE)
143-143: Enum value name "FutureHeight" should be prefixed with "ERROR_CODE_".
(ENUM_VALUE_PREFIX)
143-143: Enum value name "FutureHeight" should be UPPER_SNAKE_CASE, such as "FUTURE_HEIGHT".
(ENUM_VALUE_UPPER_SNAKE_CASE)
🔇 Additional comments (20)
proxy/jsonrpc/errors.go (3)
3-7: LGTM: Imports are appropriate and concise.The imported packages are relevant to the function's purpose.
go-jsonrpcis used for error handling, andgo-dais the source of error codes and types.
9-10: LGTM: Function signature is well-defined.The function
getKnownErrorsMapping()has a clear, descriptive name and returns the appropriate typejsonrpc.Errors. Its unexported status (lowercase first letter) is suitable for internal use within the package.
11-21: Verify completeness of error mappings.It's important to ensure that all relevant error codes from the
go-dapackage are mapped in this function. Please verify that no essential error codes are missing from this list.To help with this verification, you can run the following script:
This script will help you compare the error codes defined in the
go-dapackage with those registered ingetKnownErrorsMapping. Please review the output to ensure all necessary error codes are included.proxy/jsonrpc/server.go (1)
35-35: Enhance error handling with known error mappingThe addition of
jsonrpc.WithServerErrors(getKnownErrorsMapping())aligns well with the PR objectives of implementing custom error types. This change will improve error reporting in the JSON-RPC server.To ensure the correctness of this change, please verify the following:
- The
getKnownErrorsMapping()function is properly defined and imported.- Client-side error handling is updated to handle the new error format, if necessary.
Run the following script to verify the
getKnownErrorsMapping()function:Consider adding a comment explaining the purpose of this new option, for example:
// Use custom error mapping to enhance error reporting rpc := jsonrpc.NewServer(jsonrpc.WithServerErrors(getKnownErrorsMapping()))Ensure that the documentation is updated to reflect these changes in error handling. This will help maintain consistency between the code and its documentation, making it easier for developers to understand and use the updated error reporting system.
✅ Verification successful
Enhance error handling with known error mapping - Verified
The addition of
jsonrpc.WithServerErrors(getKnownErrorsMapping())has been verified. ThegetKnownErrorsMapping()function is properly defined inproxy/jsonrpc/errors.go, and no missing imports were found. This change improves error reporting in the JSON-RPC server.Consider adding a comment explaining the purpose of this new option, for example:
// Use custom error mapping to enhance error reporting rpc := jsonrpc.NewServer(jsonrpc.WithServerErrors(getKnownErrorsMapping()))Ensure that the documentation is updated to reflect these changes in error handling. This will help maintain consistency between the code and its documentation, making it easier for developers to understand and use the updated error reporting system.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the existence and import of getKnownErrorsMapping() function # Test 1: Search for the function definition echo "Searching for getKnownErrorsMapping() function definition:" rg --type go "func getKnownErrorsMapping\(\)" # Test 2: Check for imports in the current file echo "Checking imports in proxy/jsonrpc/server.go:" rg --type go "^import \(" proxy/jsonrpc/server.go -A 10Length of output: 572
proto/da/da.proto (1)
146-148: LGTM: ErrorDetails messageThe
ErrorDetailsmessage is well-structured and appropriate for conveying error information. It effectively uses theErrorCodeenum, providing a clear and concise way to include error details in responses.test/test_suite.go (2)
84-86: Improved error handling and assertionThe changes in the
CheckErrorsfunction enhance the error handling and assertion:
- The error message for an invalid blob ID is now more specific ("invalid blob id" instead of just "invalid").
- An additional assertion using
assert.ErrorIschecks for the specific error typeda.ErrBlobNotFound.These improvements align well with the PR objective of enhancing error handling and using custom error types. The code is now more robust and provides better error information.
Line range hint
1-167: Overall improvements in error handling and assertionsThe changes in this file consistently enhance the test suite by:
- Utilizing custom error types (
da.ErrBlobNotFound,da.ErrFutureHeight) instead of generic errors.- Improving assertions with
assert.ErrorIsto check for specific error types.- Providing more descriptive error messages.
These improvements align well with the PR objectives of enhancing error handling and using custom error types. The test suite is now more robust and provides better error information, which will help in identifying and debugging issues more effectively.
proxy/grpc/client.go (7)
62-62: LGTM. Consistent error handling.The change maintains consistency in error handling across client methods by using
tryToMapError.
73-73: LGTM. Consistent error handling maintained.The change continues the consistent use of
tryToMapErrorfor standardized error handling across client methods.
106-106: LGTM. Error handling consistency maintained.The change continues the pattern of using
tryToMapErrorfor consistent error handling across client methods.
122-122: LGTM. Consistent error handling approach.The change maintains the consistent use of
tryToMapErrorfor standardized error handling in theSubmitmethod.
144-144: LGTM. Error handling consistency maintained.The change in the
SubmitWithOptionsmethod continues the pattern of usingtryToMapErrorfor consistent error handling.
163-163: LGTM. Note the different error return pattern.The change maintains consistency in using
tryToMapError. However, note that in this method, the error is returned alongside the response results, which differs from other methods. Ensure this pattern is intentional and properly handled by callers.To verify the consistency of error handling in callers, please run:
✅ Verification successful
Verification Successful: Consistent Error Handling Confirmed.
All callers of theValidatemethod properly handle the returned errors, either by asserting no errors or by appropriately propagating them. The change to return errors alongside response results maintains consistency across the codebase.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for consistent error handling in Validate method callers # Test: Search for calls to the Validate method and their error handling rg --type go -A 5 'Validate\(.*\)' | grep -v 'func.*Validate'Length of output: 4293
46-46: LGTM. VerifytryToMapErrorimplementation.The change standardizes error handling by using
tryToMapError. This is consistent with the PR objective to enhance error handling.To ensure the correct implementation of
tryToMapError, please run the following script:✅ Verification successful
Verified the
tryToMapErrorimplementation. The function correctly standardizes error handling by appropriately mapping gRPC errors, ensuring consistency across client methods. No issues found.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of tryToMapError function # Test: Search for the tryToMapError function definition rg --type go -A 10 'func tryToMapError'Length of output: 539
Script:
#!/bin/bash # Description: Retrieve the full implementation of the tryToMapError function rg --type go -A 20 'func tryToMapError'Length of output: 909
test/dummy.go (3)
78-78: Improved error handling with custom error typeThe change from a string-based error to
da.ErrBlobNotFound{}is a good improvement. It aligns with the PR objective of using custom error types, which enhances error handling and makes it easier to handle specific error cases programmatically.
90-90: Enhanced error handling with descriptive custom error typeThe replacement of
ErrTooHighwithda.ErrFutureHeight{}is a positive change. It not only aligns with the PR objective of using custom error types but also provides a more descriptive name for the error condition. This improvement enhances code readability and makes error handling more robust.
Line range hint
1-180: Verify error handling in dependent codeThe changes to error handling in
DummyDAimprove the overall error management by using custom error types. This aligns well with the PR objectives and enhances the robustness of the error handling mechanism.To ensure smooth integration:
- Verify that all code dependent on
DummyDAis updated to handle these new error types correctly.- Update any relevant documentation to reflect these changes in error handling.
To help with the verification, you can run the following script to find potential places where the error handling might need to be updated:
This will help identify areas where
DummyDAis used and error handling is performed, which may need to be updated to handle the new error types.✅ Verification successful
Error handling in dependent code is properly managed
The shell script results indicate that there are no external dependencies using
DummyDAthat require updates to handle the new custom error types. Therefore, the changes to error handling inDummyDAare verified and pose no issues.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for uses of DummyDA and potential error handling rg --type go "DummyDA" -C 5 | rg "if err != nil"Length of output: 79
proxy/grpc/errors.go (1)
32-53: Handle all possible error codes inerrorForCode.Currently, the
errorForCodefunction does not cover all potential error codes defined inpbda.ErrorCode. To ensure all error codes are appropriately mapped, consider adding cases for any missing error codes or implementing a default case that provides more context about the unknown code.Run the following script to list all error codes not handled:
proxy/jsonrpc/client.go (2)
114-114: Ensure correct usage ofjsonrpc.NewMergeClientwith error mapping.On line 114, the
jsonrpc.NewMergeClientfunction is called with the additional optionjsonrpc.WithErrors(errs). Verify that theerrsvariable is structured correctly as per the expectations ofjsonrpc.WithErrors(). This ensures that custom error handling is integrated properly with the JSON-RPC client.Check the
go-jsonrpcpackage documentation to confirm thatjsonrpc.WithErrors(errs)accepts the correct format and thaterrsmatches the required structure.
112-112: Verify the existence and accessibility ofgetKnownErrorsMapping().On line 112, the function
getKnownErrorsMapping()is called, but its implementation is not shown in this file. Please ensure thatgetKnownErrorsMapping()is properly defined and accessible within the codebase to prevent any compilation errors.Run the following script to confirm that
getKnownErrorsMappingis defined:✅ Verification successful
getKnownErrorsMapping()is properly defined and accessible withinproxy/jsonrpc/client.go, ensuring no compilation issues.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for the definition of `getKnownErrorsMapping` in Go files. # Test: Look for the function definition. Expect: At least one match. rg --type go --no-filename --no-line-number --context 2 'func\s+getKnownErrorsMapping\s*\('Length of output: 362
Script:
#!/bin/bash # Description: Verify if the package containing `getKnownErrorsMapping` is imported in client.go. # Step 1: Find the file path where `getKnownErrorsMapping` is defined. definition_file=$(rg --type go --files-with-matches 'func\s+getKnownErrorsMapping\s*\(' | head -n 1) # Step 2: Extract the package name from the definition file. package_name=$(rg --type go '^package\s+' "$definition_file" | awk '{print $2}') # Step 3: Check if this package is imported in proxy/jsonrpc/client.go. rg --type go "import\s+\(\s+\"$package_name\"\s+\)" proxy/jsonrpc/client.goLength of output: 294
Centralize the error code to error type mapping by creating a reusable `getKnownErrorsMapping` function. This change reduces code redundancy and improves maintainability.
Unified the indentation style for all enum entries in ErrorCode. This improves code readability and consistency within the proto file.
tzdybal
force-pushed
the
tzdybal/errors
branch
2 times, most recently
from
e00bb86
to
0974e2a
Compare
tzdybal
force-pushed
the
tzdybal/errors
branch
from
0974e2a
to
181b674
Compare
tzdybal
force-pushed
the
tzdybal/errors
branch
from
a008c3a
to
61b9787
Compare
tzdybal
requested review from
tuxcanfly,
MSevey,
yarikbratashchuk and
Manav-Aggarwal
|
|
||
| // Codes are used by JSON-RPC client and server | ||
| const ( | ||
| CodeBlobNotFound Code = 32001 |
There was a problem hiding this comment.
just out of curiosity, any specific reasoning behind using 32000s?
There was a problem hiding this comment.
It satisfies the jsonrpc error spec: https://www.jsonrpc.org/specification#error_object
| } | ||
|
|
||
| // GRPCStatus returns the gRPC status with details for an ErrBlobNotFound error. | ||
| func (e *ErrBlobNotFound) GRPCStatus() *status.Status { |
There was a problem hiding this comment.
[non-blocking] nit: I'd move these into the grouping for each type for consistency.
type
func Error()
func GRPCStatus()
There was a problem hiding this comment.
[non-blocking] I think we could do the following to deduplicate some code couldn't we?
type Code int
// Define all error codes
const (
codes....
)
// Define generic type that satisfies the Errors interface
type DAError struct {
message
errorCode
grpcCode
}
func (e *DAError) Error() string {
return e.message
}
func (e *DAError) GRPCStatus() *status.Status {
return getGRPCStatus(e, e.errorCode, e.protoCode)
}
// Define all errors
var (
ErrBlobNotFound = &DARError{
message: "blob: not found",
errorCode: codes.NotFound,
protoCode: pbda.ErrorCode_ERROR_CODE_BLOB_NOT_FOUND,
}
...
)
Overview
ErrTooHighintoErrFutureHeight(renamed, moved, added error code)Resolves #65
Summary by CodeRabbit
New Features
Bug Fixes
Tests