Testet not syncing

[cl-co-dr]

Trying to snapsync testnet on a fresh node doesn't work. Looks like peers issue

[cl-co-dr]

@ClaytonNorthey92 can you look into this, is there a specific branch that is working ?

[azgms]

Following up from an operator attempting testnet snap sync (execution-layer + op-geth snap) with the official compose static peers:

Observation: the published statics connect, but never deliver blocks gossip — opp2p_peers shows gossipBlocks=true on 34.147.95.117 yet timeInMesh=0 / firstMessageDeliveries=0 indefinitely (same pattern on our hemi-mainnet statics). One static (34.34.97.92) only negotiates /ipfs/ping. With no unsafe payloads, op-node never issues engine_forkchoiceUpdated to a tip, so geth sits at genesis with eth/69 peers advertising tip.

Manually FCUing a public tip hash does start beacon header sync + chain download against the EL bootnodes, so EL P2P snap itself works once a target exists.

On a successful mainnet snap in #22, op-node itself FCUs a tip (Forkchoice requested sync to new head). Can you clarify the intended bootstrap path when static peers do not mesh-gossip blocks — e.g. should BSS/BFG drive that FCU after TBC, or are there additional gossip/req-resp peers we should pin? Happy to share more logs if useful.

[azgms]

Follow-up on EL peer scarcity for testnet snap:

Published EL enodes (only these three in hemi-node testnet/l2-config.toml):

1. enode://545da2…@34.147.95.117:30303 — connects, same image bce106a0, advertises snap/1, but drops with Message handling failed in snap err=EOF once state download starts. Chain download (headers/bodies/receipts) to tip works against this peer.
2. enode://5e0a6f7…@34.34.97.92:30303 — TCP open from our network, but will not stay as an eth peer (only ci: add lint workflow #1 remains connected).
3. enode://9ff0f63…@34.90.95.68:30303 — TCP timeout from Equinix Amsterdam.

Discovery (NoDiscovery=false + BootstrapNodes) finds no additional peers. No third-party public enodes appear in docs/operator repos for chain 743111.

We are stuck with chain sync at 100% and syncedAccounts=0 because no peer serves snap state. Are there additional snap-capable EL peers we should pin, or is state snap expected to work against bootnode #1 only (and currently broken)?