Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EnvFilter::from_default_env() prints warning when RUST_LOG is not set #2046

Closed
wg opened this issue Apr 3, 2022 · 0 comments
Closed

EnvFilter::from_default_env() prints warning when RUST_LOG is not set #2046

wg opened this issue Apr 3, 2022 · 0 comments

Comments

@wg
Copy link

wg commented Apr 3, 2022

Bug Report

Version

├── tracing v0.1.32
│   ├── tracing-attributes v0.1.20 (proc-macro)
│   └── tracing-core v0.1.24
└── tracing-subscriber v0.3.10
    ├── tracing v0.1.32 (*)
    ├── tracing-core v0.1.24 (*)
    └── tracing-log v0.1.2
        └── tracing-core v0.1.24 (*)

Platform

macOS

Description

EnvFilter from tracing-subscriber 0.3.10 prints ignoring ``: invalid filter directive when the RUST_LOG environment variable is not set. I believe this is caused by the new Builder's from_env_lossy function using unwrap_or_default() which will return an empty string when the env var is not set: https://github.com/tokio-rs/tracing/blob/master/tracing-subscriber/src/filter/env/builder.rs#L166

@hawkw hawkw closed this as completed in c7407c4 Apr 8, 2022
hawkw pushed a commit that referenced this issue Apr 8, 2022
…#2052)

## Motivation

See issue #2046. When using calling [`Builder::parse`] or
[`Builder::parse_lossy`] with  an empty string an error is produced.
This happens for example when `EnvFilter::from_default_env()` is called,
but the `RUST_LOG` variable is unset. This regression was introduced by
#2035.

## Solution

Filter any empty directives. This allows the whole string to be empty,
as well as leading and trailing commas. A unit test was added for
[`Builder::parse`], but not [`Builder::parse_lossy`] because it (per
definition) doesn't produce any side effects visible from tests when
erroring.

Fixes #2046

[`Builder::parse`]: https://github.com/tokio-rs/tracing/blob/cade7e311848227348c9b3062e4a33db827a0390/tracing-subscriber/src/filter/env/builder.rs#L151=
[`Builder::parse_lossy`]: https://github.com/tokio-rs/tracing/blob/cade7e311848227348c9b3062e4a33db827a0390/tracing-subscriber/src/filter/env/builder.rs#L135=
hawkw pushed a commit that referenced this issue Apr 9, 2022
…#2052)

## Motivation

See issue #2046. When using calling [`Builder::parse`] or
[`Builder::parse_lossy`] with  an empty string an error is produced.
This happens for example when `EnvFilter::from_default_env()` is called,
but the `RUST_LOG` variable is unset. This regression was introduced by
#2035.

## Solution

Filter any empty directives. This allows the whole string to be empty,
as well as leading and trailing commas. A unit test was added for
[`Builder::parse`], but not [`Builder::parse_lossy`] because it (per
definition) doesn't produce any side effects visible from tests when
erroring.

Fixes #2046

[`Builder::parse`]: https://github.com/tokio-rs/tracing/blob/cade7e311848227348c9b3062e4a33db827a0390/tracing-subscriber/src/filter/env/builder.rs#L151=
[`Builder::parse_lossy`]: https://github.com/tokio-rs/tracing/blob/cade7e311848227348c9b3062e4a33db827a0390/tracing-subscriber/src/filter/env/builder.rs#L135=
cgwalters added a commit to cgwalters/rpm-ostree that referenced this issue Apr 9, 2022
We managed to ship this bug in the current 2022.6 release:
tokio-rs/tracing#2046

Which is definitely embarassing enough to cut a new release.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant