Etan Kissling

Useful metrics would be: - number of open file descriptors: `process_open_fds` - libp2p peer count, mesh health & fanout health If you have a grafana dashboard, a screenshot showing the...

Thanks for confirming with the Grafana screenshot. That constant, steady increase in `process_open_fds` over time suggests that the resource leak in the async library as mentioned above is indeed present....

The reproduction instructions can't be correct, as the graffiti is in `.data.block.body.graffiti` not in `.data.body.graffiti`. Running this against my local Nimbus-BN also suggests that this is not an issue: ```zsh...

On Goerli, a similar situation actually comes up even though the number of available peers is very high. Sync manager only considers peers viable that report a higher slot progress...

Example: ``` peers: 3 ❯ finalized: 07f3e42a:7342 ❯ head: fe749777:7344:8 ❯ time: 15297:2 (244754) ❯ sync: 01d12h44m (48.41%) 0.9467slots/s (QwwwwQwwwQ:117503)/opt ```

Regarding the point above: - Suppressing descoring / disconnects while having < `SyncWorkersCount` peers e.g., by changing: ```nim proc checkPeerScore*[A, B](pool: PeerPool[A, B], peer: A): bool ``` to not kick...

Only the earliest task can enter `P`. If it fails `D` and there is no un-acquired peer to retry it (low peer scenario), it will be stuck at `w`. Minimal...

Yes, if the network has enough healthy peers it recovers eventually. This was observed on a tiny devnet with only 10 nodes in total, half of them providing incomplete responses...

- For the [`/eth/v1/beacon/light_client/finality_update`](https://ethereum.github.io/beacon-APIs/#/Beacon/getLightClientFinalityUpdate) endpoint, part of this is due to some blocks simply not including a good sync aggregate, in this case you have to wait for the next...

> It could of course also be that my script is wrong and doesn't decode the sync committee correctly, hence the question of whether I understood something wrong when reading...