lighthouse/beacon_node/network/src
Paul Hauner 84843d67d7 Reduce some EE and builder related ERRO logs to WARN (#3966)
## Issue Addressed

NA

## Proposed Changes

Our `ERRO` stream has been rather noisy since the merge due to some unexpected behaviours of builders and EEs. Now that we've been running post-merge for a while, I think we can drop some of these `ERRO` to `WARN` so we're not "crying wolf".

The modified logs are:

#### `ERRO Execution engine call failed`

I'm seeing this quite frequently on Geth nodes. They seem to timeout when they're busy and it rarely indicates a serious issue. We also have logging across block import, fork choice updating and payload production that raise `ERRO` or `CRIT` when the EE times out, so I think we're not at risk of silencing actual issues.

#### `ERRO "Builder failed to reveal payload"`

In #3775 we reduced this log from `CRIT` to `ERRO` since it's common for builders to fail to reveal the block to the producer directly whilst still broadcasting it to the networ. I think it's worth dropping this to `WARN` since it's rarely interesting.

I elected to stay with `WARN` since I really do wish builders would fulfill their API promises by returning the block to us. Perhaps I'm just being pedantic here, I could be convinced otherwise.

#### `ERRO "Relay error when registering validator(s)"`

It seems like builders and/or mev-boost struggle to handle heavy loads of validator registrations. I haven't observed issues with validators not actually being registered, but I see timeouts on these endpoints many times a day. It doesn't seem like this `ERRO` is worth it.

#### `ERRO Error fetching block for peer     ExecutionLayerErrorPayloadReconstruction`

This means we failed to respond to a peer on the P2P network with a block they requested because of an error in the `execution_layer`. It's very common to see timeouts or incomplete responses on this endpoint whilst the EE is busy and I don't think it's important enough for an `ERRO`. As long as the peer count stays high, I don't think the user needs to be actively concerned about how we're responding to peers.

## Additional Info

NA
2023-02-12 23:14:08 +00:00
..
beacon_processor Reduce some EE and builder related ERRO logs to WARN (#3966) 2023-02-12 23:14:08 +00:00
router Adding light_client gossip topics (#3693) 2022-12-13 06:24:51 +00:00
service Filter non global ips from discovery (#3023) 2022-03-02 03:14:27 +00:00
subnet_service Improve validator monitor experience for high validator counts (#3728) 2023-01-09 08:18:55 +00:00
sync remove commas from comma-separated kv pairs (#3737) 2022-11-25 07:57:10 +00:00
error.rs Rename eth2_libp2p to lighthouse_network (#2702) 2021-10-19 00:30:39 +00:00
lib.rs Separate committee subscriptions queue (#3508) 2022-08-30 05:47:31 +00:00
metrics.rs light client optimistic update reprocessing (#3799) 2023-01-24 22:17:50 +00:00
nat.rs rust 1.53.0 updates (#2411) 2021-06-18 05:58:01 +00:00
persisted_dht.rs Rename eth2_libp2p to lighthouse_network (#2702) 2021-10-19 00:30:39 +00:00
service.rs Adding light_client gossip topics (#3693) 2022-12-13 06:24:51 +00:00
status.rs Use async code when interacting with EL (#3244) 2022-07-03 05:36:50 +00:00