Neptune-Crypto/neptune-core

stack trace printed in log when connection is received from a node on another network.

Open

#557 opened on Apr 21, 2025

View on GitHub
 (4 comments) (0 reactions) (1 assignee)Rust (45 forks)auto 404
good first issuelow priorityminor

Repository metrics

Stars
 (110 stars)
PR merge metrics
 (PR metrics pending)

Description

tl;dr: We should probably change error!("Got error: {:?}", err) to error!("Got error: {}", err) in main_loop.rs.


I get this stack trace in the logs when running a testnet node on the lan, which has other nodes connected to mainnet. In other words, one node in a connected group is stopped, then run with --network testnet. It does not have any --peer arguments, so is not attempting outbound connections.

2025-04-21T01:20:27.098149732Z  INFO ThreadId(63) neptune_cash::connect_to_peers: Established incoming TCP connection with [::ffff:192.168.2.205]:60176
2025-04-21T01:20:27.099263527Z ERROR ThreadId(63) neptune_cash::main_loop: Got error: Cannot connect with [::ffff:192.168.2.205]:60176: Peer runs main, this client runs
 testnet.

Stack backtrace:
   0: anyhow::error::<impl anyhow::Error>::msg
             at /home/danda/.cargo/registry/src/index.crates.io-6f17d22bba15001f/anyhow-1.0.95/src/backtrace.rs:27:14
   1: anyhow::__private::format_err
             at /home/danda/.cargo/registry/src/index.crates.io-6f17d22bba15001f/anyhow-1.0.95/src/lib.rs:694:13
   2: neptune_cash::connect_to_peers::answer_peer_inner::{{closure}}
             at ./src/connect_to_peers.rs:285:5
   3: neptune_cash::connect_to_peers::answer_peer::{{closure}}::{{closure}}
             at ./src/connect_to_peers.rs:226:10
   4: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::future::future::Future>::poll
             at /rustc/e71f9a9a98b0faf423844bf0ba7438f29dc27d58/library/core/src/panic/unwind_safe.rs:297:9
   5: <futures_util::future::future::catch_unwind::CatchUnwind<Fut> as core::future::future::Future>::poll::{{closure}}
             at /home/danda/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-util-0.3.31/src/future/future/catch_unwind.rs:37:42
   6: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/e71f9a9a98b0faf423844bf0ba7438f29dc27d58/library/core/src/panic/unwind_safe.rs:272:9
   7: std::panicking::try::do_call
             at /rustc/e71f9a9a98b0faf423844bf0ba7438f29dc27d58/library/std/src/panicking.rs:557:40
   8: __rust_try
...

At first I believed this to be a panic. But it is not, rather an error.

the line that causes the error is in connect_to_peers::answer_peer_inner():

    ensure!(
        peer_network == own_network,
        "Cannot connect with {peer_address}: \
        Peer runs {peer_network}, this client runs {own_network}."
    );

the ensure!() macro is anyhow::ensure!() which returns an error if the condition is not met.

the error eventually gets handled in main_loop:

                        match answer_peer(
                            stream,
                            global_state_lock,
                            peer_address,
                            main_to_peer_broadcast_rx_clone,
                            peer_task_to_main_tx_clone,
                            own_handshake_data,
                        ).await {
                            Ok(()) => (),
                            Err(err) => error!("Got error: {:?}", err),
                        }

iiuc, the stack trace occurs because the error is logged with {:?} instead of {}. Which means that any other errors from that fn will also result in a logged stack trace.

My contention is that a stack trace in the log is normally interpreted as a panic. Since this is not a panic and is occurring with normal operation, I do not think we should be logging with debug representation of the error.

$ git blame src/main_loop.rs | grep "Got error" aacc39eb2 (sword-smith 2022-07-26 12:06:11 +0200 1563) Err(err) => error!("Got error: {:?}", err), ee3795966 (sword-smith 2025-03-17 23:41:36 +0100 2577) Err(err) => error!("Got error: {:?}", err),

assigning to @Sword-Smith

Contributor guide