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
Summary
The relay's
--p2p-relay-loglevel/PLUTO_P2P_RELAY_LOGLEVELflag 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-noisyWARNs from the upstream relay handler that operators cannot quiet.Background / motivation
While investigating relay
WARNlogs we found this recurring entry: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 singlereservation_request_futureslot and replaces the in-flight one. This is benign — the latest reservation future wins and the client retries/renews — but it is logged atWARNby the upstream crate and cannot be suppressed surgically without controlling the log filter.Root cause: dead config
crates/cli/src/commands/relay.rs:100storesp2p_relay_log_levelintoConfig::libp2p_log_level.crates/relay-server/src/config.rs:44-46holds the field.--log-levelviabuild_console_tracing_config(self.log.level, ...)(crates/cli/src/commands/relay.rs:93-94), which setsoverride_env_filterto that single level string (crates/cli/src/commands/common.rs:49), consumed incrates/tracing/src/init.rs:47-51.libp2p_log_levelis 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
EnvFilterWhen
--p2p-relay-loglevelis set (non-empty), compose it into the env filter as per-target directives for the libp2p crates, e.g.:or target the relay crate specifically (
libp2p_relay=<level>). TheEnvFiltersyntax already supports comma-separated per-target directives, so this can be threaded throughbuild_console_tracing_config(e.g. add an optionallibp2p_level/extra_directivesparameter) 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:
Downside: blunt (hides all
WARN-and-below from that module path) and not operator-configurable.Acceptance criteria
--p2p-relay-loglevel/PLUTO_P2P_RELAY_LOGLEVELmeasurably changes libp2p log verbosity at runtime.Dropping existing deny/accept future...warning can be suppressed via the flag.References
crates/cli/src/commands/relay.rs:93-94,100,145-151crates/relay-server/src/config.rs:44-46crates/cli/src/commands/common.rs:32-50crates/tracing/src/init.rs:46-51libp2p-relay-0.21.1/src/behaviour/handler.rs:521,539