NethermindEth / NethermindEth/pluto

Improve `alpha test peers`: match Charon's probes; reduce timeouts

Open
#632 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug track:orchestration-cli
Dominant language
Rust
Stars
8
Forks
5
Avg merge
4d 16h
Merged PRs (30d)
37

Description

Summary

pluto alpha test peers is architecturally different from Charon's testpeers.go: instead of imperative per-test probes it runs one passive swarm event loop and synthesizes verdicts from accumulated state afterwards (build_peer_results). Concrete defects:

  • PingLoad doesn't load-test: it filters passively-observed keepalive RTTs (in-code admission at peers.rs#L944-L963); Charon spawns a new ping goroutine every second for the load window. The "Running ping load tests..." log lines wrap a phase where no pinging occurs.
  • Ping is a connectivity check (any connection, even a relay circuit, passes); PingMeasure grades .last() of whatever keepalive pings happened to land — no on-demand ping exists.
  • DirectConn dials advertised addresses once (one-shot bool), doesn't use the existing crates/p2p/src/force_direct.rs, never checks Charon's len(conns) >= 2 invariant, and with no DCUtR behaviour in PlutoBehaviour it can't hole-punch — behind NAT it always reports failure.
  • Hangs: an unreachable peer keeps peer_is_done false, so the loop runs to the global --timeout (default 1h); afterwards keep_node_alive runs for --keep-alive (default 30m). A default-flag run against a dead ENR occupies ~90 minutes. Charon bounds each test individually.
  • Self is excluded from results (Charon includes the local peer); Libp2pTCPPortOpen always fails on default flags (no --p2p-tcp-address default); scoring is a placeholder TODO.
  • alpha test all panics: all.rs#L34-L45 is unimplemented!() reachable from the CLI. The whole test module sits under #![allow(dead_code)] with a "foundation" TODO.

Proposed change

  • Add active probes: an on-demand ping path (libp2p ping behaviour request or a dedicated protocol), used by Ping/PingMeasure/PingLoad with Charon's cadences; rewrite DirectConn around force_direct with per-second retries and the 2-connection assertion.
  • Bound each test by its own timeout so unreachable peers fail fast; decouple keep-alive from the test-phase cancellation token.
  • Include the local peer; give --p2p-tcp-address a sensible default or make the self-test skip when unset.
  • Implement alpha test all per Charon's runTestAll: run beacon → validator → MEV → infra → peers sequentially, forcing each sub-config's quiet flag, and write all collected results at the end when the top-level --quiet is unset. Port the two pre-run guards — must_output_to_file_on_quiet and the --test-cases rejection — and resolve the list_test_cases(TestCategory::All) TODO, which returns an empty vec. (Removing the subcommand until this lands is still better than shipping the panic.)

Acceptance

Against one reachable and one dead ENR: results print within the per-test timeouts, ping tests measure actively, and alpha test all runs all five categories with Charon's quiet semantics instead of panicking.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with crates/cli/src/commands/test/peers.rs, especially build_peer_results and peer_is_done, then compare Charon's testpeers.go. Read crates/p2p/src/force_direct.rs and the entry points in all.rs and test/mod.rs. Done means per-test timeouts, active ping behavior, direct-connection checks, and alpha test all completing the stated reachable/dead-ENR acceptance run without panicking.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
cli, distributed-systems, networking
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.