-
Notifications
You must be signed in to change notification settings - Fork 699
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
Pvf thiserror #2958
Pvf thiserror #2958
Conversation
…validCandidate,PossiblyInvalidError; fix codec macro for PrepareError
Thank you! You're absolutely right, and sorry if it caused any confusion. It is already being fixed in #2477, and I've opened an issue about it on parity-scale-codec. Appreciate you fixing it here as well! |
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.
Looks great, thank you! If you want a tip, you can include your kusama or polkadot address in the PR body:
https://github.com/paritytech/substrate-tip-bot#pull-request-body
I'm interested in whether we can now better log some of these errors that didn't implement the Display
trait before. We should be able to log them with {}
instead of {:?}
. I'll look through the codebase later for such instances.
#[error("panic: {0}")] | ||
JobError(String), |
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.
#[error("panic: {0}")] | |
JobError(String), | |
#[error("prepare job error: {0}")] | |
JobError(String), |
(That's my bad, I forgot to update this line after renaming Panic
-> JobError
.
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.
For sure I will update:) I've noticed it but from the book description it was quite logical
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.
For consistency we could also make a prepare:
prefix for other messages in PrepareError
if it is allowed
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.
I'm interested in whether we can now better log some of these errors that didn't implement the Display trait before. We should be able to log them with {} instead of {:?}. I'll look through the codebase later for such instances.
It is a good point! Thank you! I will check these instances within the PR
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.
@mrcnski I've checked the usage of {:?}
within pvf/
and changed several ones to {}
. And also changed PrepareError
messages a little bit for consistency.
polkadot/node/core/pvf/src/error.rs
Outdated
#[error(transparent)] | ||
Preparation(PrepareError), | ||
/// The error was raised because the candidate is invalid. Should vote against. | ||
Invalid(InvalidCandidate), | ||
#[error(transparent)] |
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.
Can we have specific error messages here instead of the fall-through transparent
?
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.
Let me explain the motivation:)
InternalValidationError
already hasvalidation:
prefix in its messagesValidationError
has 1-1 match between enum variants and wrapped sub errorsAs a novice to the codebase, I am not sure how much freedom I have over the error messages
So I decided to stick with the safest solution in my opinion. But of course, if you think we should expand messages on wrapper, I will do :)
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.
Good points! If you want though, you can change this:
- For preparation, add a message like
preparation error for validation: {0}
- For internal error, maybe change the message to
internal validation error: {0}
As a novice to the codebase, I am not sure how much freedom I have over the error messages
Appreciate the humility and respect for the codebase. :)
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.
Also not sure if the change is necessary TBH so I'll leave it to your judgment. I think it's fine to err on the side of being a bit too verbose: error messages are rare and the more info they contain, the better.
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.
Agree! I've decided to use candidate validation:
prefix for ValidationError
. Thus it looks consistent
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.
A good cleanup! Makes things more clear.
If you ever want to continue working on cleaning up the error processing, we have a long-waiting #752 ;) (although I believe it should be updated and discussed further).
Thank you!:) Perhaps, I will also try that but later. The coding part is not a problem here but my lack of domain knowledge and lack of usage experience which would benefit to the mentioned task. |
/tip small |
@mrcnski A small (20 DOT) tip was successfully submitted for @maksimryndin (13zCyRG2a1W2ih5SioL8byqmQ6mc8vkgFwQgVzJSdRUUmp46 on polkadot). https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/referenda |
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.
Looks awesome, just one optional comment and then we can merge!
resolve #2157 - [x] fix broken doc links - [x] fix codec macro typo https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/node/core/pvf/common/src/error.rs#L81 (see the comment below) - [x] refactor `ValidationError`, `PrepareError` and related error types to use `thiserror` crate ## `codec` issue `codec` macro was mistakenly applied two times to `Kernel` error (so it was encoded with 10 instead of 11 and the same as `JobDied`). The PR changes it to 11 because - it was an initial goal of the code author - Kernel is less frequent than JobDied so in case of existing error encoding it is more probable to have 10 as JobDied than Kernel See paritytech/parity-scale-codec#555 ---- polkadot address: 13zCyRG2a1W2ih5SioL8byqmQ6mc8vkgFwQgVzJSdRUUmp46 --------- Co-authored-by: s0me0ne-unkn0wn <[email protected]>
resolve #2157
ValidationError
,PrepareError
and related error types to usethiserror
cratecodec
issuecodec
macro was mistakenly applied two times toKernel
error (so it was encoded with 10 instead of 11 and the same asJobDied
). The PR changes it to 11 becauseSee paritytech/parity-scale-codec#555
polkadot address: 13zCyRG2a1W2ih5SioL8byqmQ6mc8vkgFwQgVzJSdRUUmp46