feat(cli): beacon CLI tests

[mskrzypkows]

CLI beacon tests ported from Charon, fixes #233

[Copilot]

Pull request overview

Ports the beacon-node CLI test suite into pluto-cli, implementing connectivity/latency/load/simulation checks against beacon endpoints (issue #233).

Changes:

• Implemented full alpha test beacon command logic (test discovery, execution, scoring, JSON output, optional publish).
• Added endpoint URL credential parsing + optional HTTP Basic Auth application for test requests.
• Extended Duration wrapper to support ordering and nanosecond comparisons used by simulation evaluation.

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
crates/cli/src/main.rs	Initializes tracing for alpha test command path.
crates/cli/src/duration.rs	Adds as_nanos, Ord, and conversion to std::time::Duration to support simulation metrics.
crates/cli/src/commands/test/mod.rs	Beacon test case listing; adds endpoint URL credential parsing + basic auth; adjusts test filtering API; updates request RTT path.
crates/cli/src/commands/test/beacon.rs	Replaces stub with full beacon test suite implementation (ping/measure/version/sync/peer-count/load/simulation).
crates/cli/Cargo.toml	Adds tracing-subscriber dependency needed by CLI tracing init.
Cargo.lock	Locks tracing-subscriber as a dependency of pluto-cli.

Comments suppressed due to low confidence (1)

crates/cli/src/commands/test/mod.rs:756

• request_rtt returns Ok(rtt) even when status != expected_status (it only logs a warning). The beacon tests treat Ok(_) as success (e.g., Ping sets verdict Ok), so endpoints returning the wrong status can still be marked as passing. Consider returning an error (or a richer result containing both RTT and status) when the status code doesn't match expected_status, and update callers accordingly.

    let status = response.status();
    if status != expected_status {
        match response.text().await {
            Ok(body) if !body.is_empty() => tracing::warn!(
                status_code = status.as_u16(),
                expected_status_code = expected_status.as_u16(),
                endpoint = clean_url,
                body = body,
                "Unexpected status code"
            ),
            _ => tracing::warn!(
                status_code = status.as_u16(),
                expected_status_code = expected_status.as_u16(),
                endpoint = clean_url,
                "Unexpected status code"
            ),
        }
    }

    Ok(rtt)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[varex83]

Thanks for the PR! Can you fix the linter please?

[mskrzypkows]

sure, I'm resolving rest copilot comments

[mskrzypkows]

Addressed all @copilot comments

[Copilot]

@mskrzypkows I've opened a new pull request, #296, to work on those changes. Once the pull request is ready, I'll request review from you.

[mskrzypkows]

Also added a docker compose to easier run beacon test, e.g.:

cargo run --bin pluto -- alpha test beacon --test-cases Ping,PingMeasure --endpoints http://localhost:5052

[emlautarom1]

Did not fully review the code but I don't want to block any further. Left several comments, in particular regarding cancellation

[mskrzypkows]

I'll address the rest of the comments soon.

[emlautarom1]

Don't want to block on this one. There are a couple of things that can be addressed on future PRs. Before merging I would ask to move the .json files to a directory closer to their usage rather than having them at the top level.

Appreciate your work!

[emlautarom1]

As a rule of thumb, you only cancel a CancellationToken if you own it, where "own" it means that you created it (not in the Rust sense of ownership). If you need to do local cancellation use .child_token() to create a local CancellationToken.

---

The reason for this is to avoid situations where the parent that passed a CancellationToken gets cancelled due to the child cancelling the token. For reference:

• In Go, when you create a context you get the context itself + a CancelFunc, and only the former is passed to child functions/goroutines. Creating a child context does not grant the ability to cancel the parent.
• In C#, a CancellationToken can only be created through a CancellationTokenSource, and only the former is passed to child functions/tasks, while the later is the only object that provides the Cancel() operation.

[emlautarom1]

For reference, here in the Go implementation there is a local context pingCtx created from the arguments ctx. Here, ctx would be our cancel argument, but we're missing the equivalent of pingCtx (the local CancellationToken)

[mskrzypkows]

I've pushed json files by mistake, removing them...

[varex83]

LGTM!

One small thing, and it's GTG