Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
downloading & parsing blobs #75
downloading & parsing blobs #75
Changes from 25 commits
8059330
1d6cff4
84fdf7c
6d123be
95030aa
c95727f
7e37172
6c21352
7340fa0
177d7e1
85d4138
4541901
da19054
2714dc1
0d54a35
705193c
f57f69e
af59397
fc72f40
21a1a2a
3b25ad0
00b097a
e06c60d
310de5d
1031503
23a7563
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
How does this look? It accomplishes pretty much the same thing as it did previously, but in my opinion it's a lot more readable this way.
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.
But it isn't the same thing at all... In case response cannot be retrieved, I want to see the error (I don't think I ever did - I suppose it's there for some complicated HTTP stuff that doesn't really happen, but who knows), not just try again...
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 will give you the error if the response fails though, that part hasn't been changed at all.
However, another thing I thought of: we should actually be getting the response as a json directly instead of getting it as a string and then parsing it as one.
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.
Well, no. Let's say I replace the
Ok(text) = response.text()
withErr(x) = response.text()
, to simulate the failure (full executable code is in https://github.com/eqlabs/zksync-state-reconstruct/tree/inversion ). Then I can runcargo run reconstruct l1 --http-url https://eth.llamarpc.com --start-block 19428415
to check some blobs, and getNo error is logged, and really I don't see how it could...
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.
That link is for sending JSON, but yes, something like https://docs.rs/reqwest/latest/reqwest/struct.Response.html#method.json should be possible - except I don't see how to get the response text after failing to parse it as JSON... Really, all I want here is error handling - get response, report error on failure, then parse it, report error on failure... If that's more elaborate than some online Rust examples, well, so what?
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.
That code is testing that we can decode the response, not get the response. Getting the response is still handled with a
match
statement like it was previously.I'll admit, I don't really see why we would need that level of error logging. Failing to parse it as JSON is in my mind more than good enough, since that tells the user exactly what went wrong - it's not a valid JSON response.
And for the error handling part, if you're insistent, I would highly recommend looking into more advanced
thiserror
uses, like the#[from]
derive. That allows you to do what you want, without polluting the code with so much boilerplate. If you go down this road, I'd also suggest makingBlobError
it's own error type that can then be condensed to aParseError
.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.
There are 2 async calls needed to get the response:
send
(insideBlobHttpClient::retrieve_url
) andtext
. Both can fail, and both should be tested. I want to log the second one, precisely because I do not expect the error to happen.Well, to debug the problems that we've already had (e.g. the wrong URL returning JSON without a
data
attribute - looking at it, it's obvious it says NOT_FOUND, but a serde parser will loose that info).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.
Gotcha, sure. in that case we should definitely be using the
?
operator in combination withthiserror
-style error handling then since that would be an unrecoverable error. See my comment above for details.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 wondering if we should supply a default URL at all. With the ETH-RPC URL, we made the decision to only give one as an example in the README, as opposed to hard-coding in a default one.
Of course this will depend on if blob providers can be counted on to use compatible formats. But, if it's possible, I'd prefer not tying ourselves to one specific provider.
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 aren't tying ourselves - it's configurable... We're just being pushed, to the only blob archive there is... Anyway, this URL isn't directly analogical to the ETH-RPC URL, because it isn't always needed - if the user reconstructs only old blocks, it isn't necessary...