Improve error handling in api.go #106
Labels
No Label
bug
critical
documentation
duplicate
enhancement
Epic
good first issue
help wanted
Integration tests
invalid
question
v5
wontfix
Copied from Github
Kind/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: cerc-io/ipld-eth-server#106
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
We need to manage the bubbling up of multiple errors better. Most API methods have the propensity of having two errors to return at the end of the method: an error internal to the method itself and an error returned by a call out to a proxy client if there was an internal error. Right now we give precedence to the internal errors, but it would be better to track both (in
[]error
), and on return concatenate both messages and return a composite error.Additionally, for the the
eth_call
method, we have two more potential errors to track: thenewRevertError
and theresult.Err
. In this case it would be particularly helpful to expose all these errors, of which all 4 could potentially occur in a single call.See https://github.com/vulcanize/ipld-eth-server/pull/105#discussion_r719370160
@dboreham @telackey If this has been resolved please close.