-
Notifications
You must be signed in to change notification settings - Fork 773
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
client: Snap Sync Scenario Improvements #3200
Conversation
Codecov ReportAttention:
Additional details and impacted files
Flags with carried forward coverage won't be shown. Click here to find out more. |
…to snap-sync-debugging
…s-monorepo into snap-sync-debugging
Updated this via UI. @scorbajio what is the status of this PR? |
This is ready for review. cc @g11tech |
@@ -27,7 +27,7 @@ import type { Job, SnapFetcherDoneFlags } from './types' | |||
import type { Debugger } from 'debug' | |||
const { debug: createDebugLogger } = debugDefault | |||
|
|||
const TOTAL_RANGE_END = BIGINT_2 ** BIGINT_256 - BIGINT_1 | |||
const TOTAL_RANGE_END = BigInt(BIGINT_2 ** BIGINT_256 - BIGINT_1) |
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.
wouldn't this be bigint anyway?
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.
Yes, I think this was something I did while debugging and forgot to clean up. Fixed.
|
||
if (task.multi === true) { | ||
// peer does not respect origin or limit for multi-account storage fetch | ||
return setLengthLeft(bigIntToBytes(BIGINT_0), 32) |
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.
even if peer doesn't respect the origin or limit, but if we provide it, does it give an issue (just curious)
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 seems like origin/limit is still used while servicing the request, but it's a bit open ended (see https://github.com/ethereum/go-ethereum/blob/a193bb0c730e413db56424a084cc172892c68dd5/eth/protocols/snap/handler.go#L346). I just use the max range if it's a multi-account request to be safe.
origin = bigIntToBytes(first + BIGINT_1) | ||
let origin: Uint8Array | ||
|
||
try { |
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.
could you add a comment to code which particular error scenario motivated you to put this in try/catch
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.
The parsing of partialResult was resulting in indexing and undefined errors since lastSlot was an array in certain instances instead of a slot object. I may need to rethink some of the typing we are doing in the fetchers, that's why it was necessary to use ts-ignore
. I will add a comment about it to the code.
Updated this via UI |
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.
Seems all review comments from @g11tech are adressed.
Will merge.
The goal of this PR is to debug the current snap sync implementation and verify that the following scenarios from @g11tech are handled as expected: