Peer disconnected during identify protocol

[twoeths]

Describe the bug

after #8188 I found too many "Peer disconnected during identify protocol" and it only happens on some specific peers

on one of fusaka-devnet-3 nodes:

grep -e "Peer disconnected during identify protocol" -rn beacon-2025-08-31.log | wc -l
146806

we need to review if calling libp2p.identify is suitable inside onLibp2pPeerConnect given this documentation from this method

export interface Identify {
  /**
   * Please use with caution.
   *
   * Due to the default limits on inbound/outbound streams for this protocol,
   * invoking this method when runOnConnectionOpen is true can lead to
   * unpredictable results as streams may be closed by the local or the remote
   * node.
   *
   * If you find yourself needing to call this method to discover other peers
   * that support your protocol, you may be better off configuring a topology to
   * be notified instead.
   *
   * Alternatively the libp2p node itself will emit `peer:identify` events after
   * identify has taken place which can be used to passively detect new peers.
   */
  identify(connection: Connection, options?: AbortOptions): Promise<IdentifyResult>
}

Expected behavior

• no error, or comes up with reason
• should we handle peer:identify instead? cc @wemeetagain

Steps to reproduce

No response

Additional context

No response

Operating system

Linux

Lodestar version or commit hash

unstable

[wemeetagain]

we need to review if calling libp2p.identify is suitable inside onLibp2pPeerConnect given this documentation from this method

Yes it is fine to call identify directly.

Libp2p core can automatically trigger an identify on connection open and the consumer can await the peer:identify event to handle the response. Or the consumer can disable the automatic identify, and dial the protocol manually when they want. But either way, if a peer disconnects us or if they don't support identify, the error above will be thrown.

I'm in favor of the application (from the persp of libp2p) controlling the dial, and not relying on automatic behavior. Really its all about control. It makes almost no difference, but there actually is a slight difference. Do we want to trigger a status first or an identify? In our case, we actually fire off a status and ping first, and then we call identify. If you rely on automagic, you don't get to answer that question, you just get what you get.

If the problem is the log being spammed, then lets just not log there? It's not really a problem if a peer doesn't support identify, we just won't get the agent version, which we use to make other logs more helpful.