Skip to content

Conversation

juan518munoz
Copy link

What ❔

Why ❔

Checklist

  • PR title corresponds to the body of PR (we generate changelog entries from PRs).
  • Tests for the changes have been added / updated.
  • Documentation comments have been added / updated.
  • Code has been formatted via zkstack dev fmt and zkstack dev lint.

@juan518munoz juan518munoz marked this pull request as ready for review January 21, 2025 20:59
let response = reqwest::get(url)
.await
.map_err(|e| VerificationError::LinkError(e.to_string()))
.unwrap();
Copy link
Collaborator

Choose a reason for hiding this comment

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

this unwrap should not be here

Copy link
Author

Choose a reason for hiding this comment

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

Removed all unwraps left over on the file, I'm unsure about this one tho:

impl PointFile {
    fn path(&self) -> &str {
        match self {
            PointFile::Temp(file) => file.path().to_str().unwrap_or_default(), // Safe unwrap because NamedTempFile guarantees a valid path
            PointFile::Path(path) => path,
        }
    }
}

Should we keep the unwrap with the comment, use unwrap_or_default or do anything different?

Copy link
Collaborator

@juanbono juanbono Jan 27, 2025

Choose a reason for hiding this comment

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

I think it's better to change the function's return type to std::Path since what you want is a path.

Copy link
Collaborator

@juanbono juanbono left a comment

Choose a reason for hiding this comment

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

see comments

@@ -316,9 +287,9 @@ impl RawEigenClient {

match disperser::BlobStatus::try_from(resp.status)? {
disperser::BlobStatus::Processing | disperser::BlobStatus::Dispersing => Ok(None),
disperser::BlobStatus::Failed => Err(anyhow::anyhow!("Blob dispatch failed")),
disperser::BlobStatus::Failed => anyhow::bail!("Blob dispatch failed"),
Copy link
Collaborator

Choose a reason for hiding this comment

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

we should not use anyhow here.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think it is better to have a rich error type that can be matched and handled appropriately by the caller of this module.
Anyhow is more for CLIs, end-user errors.

Copy link
Author

Choose a reason for hiding this comment

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

I think a good approach would be to apply the same type of error handling as we are doing now with the external client library, which uses thiserror, do you agree?

Copy link
Collaborator

Choose a reason for hiding this comment

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

yes

@@ -331,17 +302,12 @@ impl RawEigenClient {
let blob_info = resp.info.context("No blob header in response")?;
Ok(Some(blob_info))
}

_ => Err(anyhow::anyhow!("Received unknown blob status")),
_ => anyhow::bail!("Received unknown blob status"),
Copy link
Collaborator

Choose a reason for hiding this comment

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

remove anyhow usage

Copy link
Collaborator

Choose a reason for hiding this comment

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

same as before.

Copy link
Author

Choose a reason for hiding this comment

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

Ditto last comment

Copy link
Collaborator

Choose a reason for hiding this comment

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

yes

@gianbelinche
Copy link

We should probably add settlement_layer_confirmation_depth as a parameter to call_batch_id_to_metadata_hash, so that Box<DynClient<L1>> has it for its implementation, we would lose that functionality if we don't

@juanbono
Copy link
Collaborator

LGTM , I approved provided you fix the remaining ones

Copy link
Collaborator

@juanbono juanbono left a comment

Choose a reason for hiding this comment

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

Reviewed latest changes. LGTM

@juan518munoz juan518munoz merged commit 0575785 into eigen-client-extra-features Jan 28, 2025
11 of 23 checks passed
@juan518munoz juan518munoz deleted the eigen-client-extra-features-address-comments-third branch January 28, 2025 19:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants