Skip to content

relay: wire --p2p-relay-loglevel into the tracing filter (quiet benign libp2p relay handler warnings) #483

Description

@emlautarom1-agent

Summary

The relay's --p2p-relay-loglevel / PLUTO_P2P_RELAY_LOGLEVEL flag is captured into config but never applied to the tracing subscriber. There is currently no way to control the verbosity of libp2p's own logs independently of Pluto's --log-level. This surfaces concretely as benign-but-noisy WARNs from the upstream relay handler that operators cannot quiet.

Background / motivation

While investigating relay WARN logs we found this recurring entry:

WARN new_established_connection{...}: libp2p_relay::behaviour::handler: Dropping existing deny/accept future in favor of new one

Source: libp2p-relay-0.21.1/src/behaviour/handler.rs:521,539. It fires when a single connection sends overlapping reservation accept/deny requests; the handler keeps a single reservation_request_future slot and replaces the in-flight one. This is benign — the latest reservation future wins and the client retries/renews — but it is logged at WARN by the upstream crate and cannot be suppressed surgically without controlling the log filter.

Root cause: dead config

  • crates/cli/src/commands/relay.rs:100 stores p2p_relay_log_level into Config::libp2p_log_level.
  • crates/relay-server/src/config.rs:44-46 holds the field.
  • But the tracing filter is built only from --log-level via build_console_tracing_config(self.log.level, ...) (crates/cli/src/commands/relay.rs:93-94), which sets override_env_filter to that single level string (crates/cli/src/commands/common.rs:49), consumed in crates/tracing/src/init.rs:47-51.
  • libp2p_log_level is therefore never read → dead config.

The flag mirrors Charon's p2p-relay-loglevel, so the intent was always to control libp2p verbosity.

Suggested solution (preferred): wire the flag into the EnvFilter

When --p2p-relay-loglevel is set (non-empty), compose it into the env filter as per-target directives for the libp2p crates, e.g.:

<log-level>,libp2p=<p2p-relay-loglevel>

or target the relay crate specifically (libp2p_relay=<level>). The EnvFilter syntax already supports comma-separated per-target directives, so this can be threaded through build_console_tracing_config (e.g. add an optional libp2p_level/extra_directives parameter) or applied in the relay command before building the config. With the default empty value, behavior is unchanged.

This gives operators a real knob (parity with the flag's documented intent) and lets them quiet the libp2p relay handler noise (e.g. --p2p-relay-loglevel=error) without lowering Pluto's own log level.

Workaround (if we don't wire the flag now)

Hardcode a scoped directive for just the noisy module in the relay command:

let log_config = build_console_tracing_config(
    format!("{},libp2p_relay::behaviour::handler=error", self.log.level),
    &self.log.color,
    loki_config,
);

Downside: blunt (hides all WARN-and-below from that module path) and not operator-configurable.

Acceptance criteria

  • --p2p-relay-loglevel / PLUTO_P2P_RELAY_LOGLEVEL measurably changes libp2p log verbosity at runtime.
  • Empty/unset value preserves current behavior.
  • The benign Dropping existing deny/accept future... warning can be suppressed via the flag.

References

  • crates/cli/src/commands/relay.rs:93-94,100,145-151
  • crates/relay-server/src/config.rs:44-46
  • crates/cli/src/commands/common.rs:32-50
  • crates/tracing/src/init.rs:46-51
  • Upstream log site: libp2p-relay-0.21.1/src/behaviour/handler.rs:521,539

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions