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

Pvf thiserror #2958

Merged
merged 8 commits into from
Jan 19, 2024
Merged

Pvf thiserror #2958

merged 8 commits into from
Jan 19, 2024

Conversation

maksimryndin
Copy link
Contributor

@maksimryndin maksimryndin commented Jan 17, 2024

resolve #2157

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

@mrcnski mrcnski added T0-node This PR/Issue is related to the topic “node”. I4-refactor Code needs refactoring. R0-silent Changes should not be mentioned in any release notes T11-documentation This PR/Issue is related to documentation. labels Jan 17, 2024
@mrcnski
Copy link
Contributor

mrcnski commented Jan 17, 2024

codec macro was mistakenly applied two times to Kernel error (so it was encoded with 10 instead of 11 and the same as JobDied). I changed it to 11

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!

Copy link
Contributor

@mrcnski mrcnski left a 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.

Comment on lines 50 to 51
#[error("panic: {0}")]
JobError(String),
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
#[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.

Copy link
Contributor Author

@maksimryndin maksimryndin Jan 17, 2024

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

Copy link
Contributor Author

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

Copy link
Contributor Author

@maksimryndin maksimryndin Jan 17, 2024

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

Copy link
Contributor Author

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.

Comment on lines 30 to 33
#[error(transparent)]
Preparation(PrepareError),
/// The error was raised because the candidate is invalid. Should vote against.
Invalid(InvalidCandidate),
#[error(transparent)]
Copy link
Contributor

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?

Copy link
Contributor Author

@maksimryndin maksimryndin Jan 17, 2024

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:)

  1. InternalValidationError already has validation: prefix in its messages
  2. ValidationError has 1-1 match between enum variants and wrapped sub errors
  3. As 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 :)

Copy link
Contributor

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. :)

Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

@s0me0ne-unkn0wn s0me0ne-unkn0wn left a 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).

@maksimryndin maksimryndin marked this pull request as ready for review January 17, 2024 14:36
@maksimryndin
Copy link
Contributor Author

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.

@mrcnski
Copy link
Contributor

mrcnski commented Jan 18, 2024

/tip small

Copy link

@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 tip

Copy link
Contributor

@mrcnski mrcnski left a 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!

@mrcnski mrcnski added this pull request to the merge queue Jan 19, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jan 19, 2024
@mrcnski mrcnski added this pull request to the merge queue Jan 19, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jan 19, 2024
@mrcnski mrcnski added this pull request to the merge queue Jan 19, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jan 19, 2024
@mrcnski mrcnski added this pull request to the merge queue Jan 19, 2024
github-merge-queue bot pushed a commit that referenced this pull request Jan 19, 2024
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 <48632512+s0me0ne-unkn0wn@users.noreply.github.com>
Merged via the queue into paritytech:master with commit 47a3faa Jan 19, 2024
124 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I4-refactor Code needs refactoring. R0-silent Changes should not be mentioned in any release notes T0-node This PR/Issue is related to the topic “node”. T11-documentation This PR/Issue is related to documentation.
Projects
Status: Completed
Development

Successfully merging this pull request may close these issues.

PVF: refactor errors to use thiserror
3 participants