gnosis/lighthouse
1
0
Fork 0
mirror of https://github.com/sigp/lighthouse.git synced 2026-03-11 18:04:18 +00:00
Code Issues Packages Projects Releases Wiki Activity

Don't return errors on HTTP API for already-known messages (#3341)

Browse Source 
## Issue Addressed

- Resolves #3266

## Proposed Changes

Return 200 OK rather than an error when a block, attestation or sync message is already known.

Presently, we will log return an error which causes a BN to go "offline" from the VCs perspective which causes the fallback mechanism to do work to try and avoid and upcheck offline nodes. This can be observed as instability in the `vc_beacon_nodes_available_count` metric.

The current behaviour also causes scary logs for the user. There's nothing to *actually* be concerned about when we see duplicate messages, this can happen on fallback systems (see code comments).

## Additional Info

NA
This commit is contained in:
Paul Hauner
2022-08-10 07:52:57 +00:00
parent 052d5cf31f
commit 2de26b20f8
3 changed files with 105 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
beacon_node/http_api/src/sync_committees.rs
View File

@@ -11,7 +11,7 @@ use beacon_chain::{
use eth2::types::{self as api_types};
use lighthouse_network::PubsubMessage;
use network::NetworkMessage;
use slog::{error, warn, Logger};
use slog::{debug, error, warn, Logger};
use slot_clock::SlotClock;
use std::cmp::max;
use std::collections::HashMap;
@@ -189,6 +189,24 @@ pub fn process_sync_committee_signatures<T: BeaconChainTypes>(
verified_for_pool = Some(verified);
}
// If this validator has already published a sync message, just ignore this message
// without returning an error.
//
// This is likely to happen when a VC uses fallback BNs. If the first BN publishes
// the message and then fails to respond in a timely fashion then the VC will move
// to the second BN. The BN will then report that this message has already been
// seen, which is not actually an error as far as the network or user are concerned.
Err(SyncVerificationError::PriorSyncCommitteeMessageKnown {
validator_index,
slot,
}) => {
debug!(
log,
"Ignoring already-known sync message";
"slot" => slot,
"validator_index" => validator_index,
);
}
Err(e) => {
error!(
log,
@@ -283,6 +301,16 @@ pub fn process_signed_contribution_and_proofs<T: BeaconChainTypes>(
// If we already know the contribution, don't broadcast it or attempt to
// further verify it. Return success.
Err(SyncVerificationError::SyncContributionAlreadyKnown(_)) => continue,
// If we've already seen this aggregator produce an aggregate, just
// skip this one.
//
// We're likely to see this with VCs that use fallback BNs. The first
// BN might time-out *after* publishing the aggregate and then the
// second BN will indicate it's already seen the aggregate.
//
// There's no actual error for the user or the network since the
// aggregate has been successfully published by some other node.
Err(SyncVerificationError::AggregatorAlreadyKnown(_)) => continue,
Err(e) => {
error!(
log,