search

sigp / lighthouse

Ethereum consensus client in Rust
https://lighthouse.sigmaprime.io/
Apache License 2.0
2.83k stars 699 forks source link

Restarting the bn on a network before bc launch shows a bunch of `WARN Error processing HTTP API request` messages #3078

Open remyroy opened 2 years ago

remyroy commented 2 years ago

Description

It seems like restarting my beacon node service on a network that has not started the beacon chain genesis yet makes the beacon node process spew a bunch of these WARN Error processing HTTP API request method: GET, path: /eth/v1/node/syncing, status: 500 Internal Server Error messages.

Version

Unstable v2.1.3-e4fa7d9 - https://github.com/sigp/lighthouse/commit/e4fa7d906f999b82510ad0eab791bd092947107b

Present Behaviour

  1. I followed my guide to setup a machine for Kiln.
  2. I started the Geth service, the Lighthouse beacon node service and the Lighthouse validator client.
  3. I watched the logs and everything seemed fine.
  4. I restarted my Lighthouse beacon node service around Mar 10 21:40:04 UTC, before the beacon chain started on Kiln.
  5. I noticed these logs: https://gist.github.com/remyroy/641f0ceabb05d9f977174c6550a1fb3f#file-lhbn-log-L1950

Expected Behaviour

Under normal circumstances, I expect the Lighthouse beacon node process to behave normally after a restart.

Steps to resolve

Restarting the validator client service solved this issue for some weird reason. I restarted my validator client around Mar 10 22:11:27 UTC and you can see in the logs that the WARN messages disappeared. Full validator client logs can be found on https://gist.github.com/remyroy/4334e9b0722155ae94917c2fc2aba744 .

Now it might be harder to reproduce as it seems you need a network that has not reached beacon chain genesis yet.

pawanjay176 commented 2 years ago

So this is mainly an issue because the syncing status before genesis is undefined and the eth/v1/node/syncing endpoint therefore returns a 500 server error.

This won't cause any actual issues other than the error logs. The BN starts responding to the api request after genesis and the VC will immediately connect to it and perform any required duties. Fixing this would complicate the logic that handles fallback beacon nodes which doesn't seem worth it imo.