Fix SyncProgress() Unmarshalling#24181
Closed
jclapis wants to merge 3 commits intoethereum:masterfrom
Closed
Conversation
jclapis
requested review from
holiman,
karalabe,
rjl493456442 and
zsfelfoldi
as code owners
Contributor
|
Thanks for the quick issue report and PR! Since SyncProgress is supposed to be stable API, I have decided to fix it a bit differently in #24199. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This PR fixes #24180. It changes the fields in
ethereum.SyncProgressto behexutil.Uint64instead ofuint64so they unmarshal correctly when using the Geth library to connect to a Geth RPC endpoint.I believe this retains the spirit of the changes in PR 23576 because it unmarshals the struct all at once instead of manually handling the individual fields. However, I'm not sure if numbers being returned in
0xformat via the RPC endpoints is standard behavior or not so this might cause issues with other clients. A more robust change that retains the above spirit would be to add prefix-checking support to thehexutil.Uint64unmarshallers so it could handle incoming numbers in any format. I'm not sure if that's necessary so I've left it well-enough alone here.