-
Notifications
You must be signed in to change notification settings - Fork 11.3k
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
[fastx client] Better Error Handling & Messaging - Part 1 #256
Conversation
ffa6375
to
d3f8412
Compare
fastx_types/src/error.rs
Outdated
@@ -171,3 +178,15 @@ impl std::convert::From<PartialVMError> for FastPayError { | |||
} | |||
} | |||
} | |||
|
|||
// Assuming all errors are FastPayError, wrap all other errors in FastPayError::UnknownError | |||
impl From<anyhow::Error> for FastPayError { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this ok? @huitseeker
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is to allow method with return type Result<_,FastPayError>
to use ?
on methods returning Result<_, anyhow::Error>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is coercing a hue range of errors to a perhaps not meaningful FastPayError::UnknownError
. Can you point me to a place (or better, places) where this is used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is used in broadcast_and_execute
line 486, the method returns FastPayError and inline 561 handle.stop().await?
returns anyhow::Error.
Thinking more about this, It's probably better to change the method signature back to return anyhow::Error and wrap the FastPayError.
5a8479b
to
2892de7
Compare
fastx_types/src/error.rs
Outdated
match e.downcast_ref::<FastPayError>() { | ||
Some(e) => e.clone(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will never fire, look instead at the chain
fn on anyhow::Error
if you want to do this sort of thing.
fastx_types/src/error.rs
Outdated
@@ -171,3 +178,15 @@ impl std::convert::From<PartialVMError> for FastPayError { | |||
} | |||
} | |||
} | |||
|
|||
// Assuming all errors are FastPayError, wrap all other errors in FastPayError::UnknownError | |||
impl From<anyhow::Error> for FastPayError { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is coercing a hue range of errors to a perhaps not meaningful FastPayError::UnknownError
. Can you point me to a place (or better, places) where this is used?
I am working on refactoring the client, to make object_transfer and move_call / publish to share the same cert synchonisation code path, there are a lot of duplicated code at the moment. Will continue error handling improvement part 2 after the refactoring. |
3be5a54
to
e09e762
Compare
* bug fix: execute_transfer will not be able to execute twice if previous request failed, causing `pending_transfer` to stick.
…ransfer_object * Added From<anyhow::Error> for FastPayError * some refactoring
* new test for receive_object * new error for incorrect recipient
* check certificate order signature before receive_object
e09e762
to
87955be
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice one! A few places where we can add more or less info to the errors.
fastpay_core/src/authority.rs
Outdated
fp_ensure!( | ||
object.digest() == object_digest, | ||
FastPayError::InvalidObjectDigest | ||
FastPayError::InvalidObjectDigest { object_id } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we indicate what the expected digest was here?
fastpay_core/src/client.rs
Outdated
return Err(FastPayError::FailedToCommunicateWithQuorum { | ||
err: err.to_string(), | ||
return Err(FastPayError::QuorumNotReachedError { | ||
num_of_authorities: number_of_authorities, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here you seem to indicate the number of authorities in relation to the quorum. We often present protocol as having 3f+1 authorities and needed 2f+1 votes to get a quorum. However, in our actual protocol we have stake (with diff authorities having different stake) and expect 2/3 +1 of stake to get a quorum. So the number of authorities, wihout reference to their identity or stake is not really informative.
fastpay_core/src/client.rs
Outdated
Err(FastPayError::FailedToCommunicateWithQuorum { | ||
err: "multiple errors".to_string(), | ||
Err(FastPayError::QuorumNotReachedError { | ||
num_of_authorities: number_of_authorities, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above ...
fastpay_core/src/client.rs
Outdated
FastPayError::UnexpectedSequenceNumber { | ||
object_id: *order.object_id(), | ||
expected_sequence: self.next_sequence_number(order.object_id())?, | ||
received_sequence: order.sequence_number() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably be consistent to either report what was expected, what was provided or both. I think that what was expected is the right approach, since what was provided should be known.
This PR address issue #187
This is part one of error handling improvement, covers client apis excluding move related apis.