-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
fix(drand): add null HistoricalBeaconClient for old beacons #12830
base: master
Are you sure you want to change the base?
Conversation
Checked out this branch, and tried to see if I still encountered the #11802 issue. It got a bit longer then previous:
It then looped on the
|
OK, well I don't think the drand errors were your fatal problem here it's just looping in the background and logging those entries. But unfortunately we're stuck with the optimizing client: https://github.com/drand/drand/blob/v1.5.11/client/optimizing.go#L194, so perhaps we can't take this approach at all and need it fixed inside drand otherwise it's going to continue to speed test the null-client and spam those info log messages. I think your problem here is that you can't use a snapshot file when trying to import the full "chain". At least that's my understanding from reading the code - the main difference between importing a snapshot and importing the chain is that a chain import does a full tipset validation back to genesis, which is why it wants the beacons to be available. It calls I suppose a chain export is a |
Updated this branch with a modification that attempts to use the "watcher" mechanism in drand because watchers don't get speed tested, so if I can convince it that my historical null-client is a watcher then maybe it'll not speed test it. I haven't tested this but @rjan90 if you still have that snapshot handy, would you mind running it again to see if you get any of those INFO logs or any other errors from drand? |
Reran with the latest commit, and this is what I get:
|
e68c3e7
to
cf963a5
Compare
cf963a5
to
30ca496
Compare
OK, one tiny change and this seems to work; I grabbed my own snapshot and have been running it and the only logs are the badger ones so I believe this is solved, even if it is a hack. I'd still like @AnomalRoil to take a look and suggest alternative approaches. Marking @Kubuxu as reviewer since he's touched a lot of this stuff previously. |
Fixes: #11802
Ref: #11802 (comment)
I'm pretty sure this will work since we only need to verify, not fetch, old beacon entries. So when we remove
Servers
from the config (like we've done for Mainnet and Incentinet), this will satisfy drand but also be a noop.