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

fix(verify): make verification result an option to handle blockscout's format #2426

Merged
merged 5 commits into from
May 23, 2023

Conversation

Evalir
Copy link
Contributor

@Evalir Evalir commented May 22, 2023

Motivation

I've been investigating verification issues due to foundry-rs/foundry#4909 — and it turns out that blockscout, unlike etherscan, likes to return null on the result field sometimes, instead of an empty string on message and the actual message on the result field, like etherscan. This in turn introduced a bug when detecting if a contract was already verified as it expects that the blockscout format is identical to etherscan's.

To be a bit more specifc, this format is returned by blockscout when a contract is not verified, and this is not what etherscan returns (see the null in result):

{
  "message": "Contract source code not verified",
  "result": null,
  "status": "0"
}

While making a blockscout verification client might be the "best" fix, this is a slight difference in formats and I opted for this solution instead. We can handle separating blockscout & etherscan verification later.

Solution

Parses the result field from the API response as an Option instead of just a string, to handle cases where result is null.

Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

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

nice find!

if resp.result.starts_with("Max rate limit reached") {
let resp: Response<Option<String>> = self.get_json(&query).await?;

let result = resp.result.unwrap_or("".to_string());
Copy link
Collaborator

Choose a reason for hiding this comment

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

null will now always be a serde error,

I'd rather have a new error variant for EmptyResult or something

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done in 94ad922 — we now bubble up the error with an EmptyResult variant

Comment on lines 26 to 27
#[error("Response result is unexpectedly empty")]
EmptyResult { status: String, message: String },
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should the error message include status or message?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh yeah, let's include both! the status should only be a number so it's short. The message is what actually has the error

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done on fa5c243

@DaniPopes DaniPopes merged commit 00d10f4 into gakonst:master May 23, 2023
15 checks passed
@Evalir Evalir deleted the evalir/fix-blockscout-verification branch May 23, 2023 15:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants