-
Notifications
You must be signed in to change notification settings - Fork 9
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
eth/protocols/snap: reschedule missed deliveries #42
Conversation
My node finally seems to have gotten stranded anyway,
|
|
Hm, might be an issue with the server - here's the
So it's still generating the snapshot, and it's gong really slow. Also
It's going to go OOD shortly. We should probably wipe+resync it. However, it should still be able to serve our healing-requests, as long as it's not more than 64 blocks behind the canon head, right? |
It eventually completed sync! |
1508fac
to
6776e15
Compare
6776e15
to
ad11e6e
Compare
rebased |
This time when I ran it, it finished gracefully:
But then it started wiping -- which seems a bit odd?
So after wiping for a minute, the snapshot generation started:
|
Opened against master instead |
This (hopefully) fixes a flaw, where a remote peer rejects the request. Previously, we would seemingly not reschedule the request, until the next sync cycle. For some reason, which I'm not fully clear about, it could get stuck for hours (my NUC was stuck on the same things for >12 hours), requesting (and getting rejected) the same segments from the same peer(s).
This PR reverts the request if the remote side cannot deliver, so it can be rescheduled for another peer.
Example output when running it
My machine is now in the final stages of healing, so looking good so far