Repository navigation
All logging and command line error messages are totally broken in master ["solved"] #3006
Description
Rocket Version
master
Operating System
Debian 13
Rust Toolchain Version
rustc 1.97.1 (8bab26f4f 2026-07-14)
What happened?
When I run a Rocket app from the most recent release (0.5.1), if I do not specify a log_level as described here, a helpful debug output goes to stdout. If I upgrade my Rocket app to the newest master commit 3a54d079aef (or even any master as recent as 042b6458e7bc53), this debug output disappears. This is not a defaults problem; adding a Rocket.toml with explicit [default]\nlog_level="debug" does not cause the output to reappear.
In addition to regular logs being missing, error messages do not appear. For example imagine I misconfigure my Rocket.toml such I have [default]\naddress="192.168.0.1" but in fact my address is 192.168.0.2. This causes Rocket to immediately quit on launch, but there is no error message indicating why. Similarly [default]\nlog_level=debug (incorrect due to lack of quotation marks) will cause a Rust panic, with an unhelpful stack trace, again without an error message. 0.5.1 would have printed clear errors in any of these cases, even with log_level="off".
As a final odd note, as mentioned, with [default]\nlog_level="debug" the app runs but if I change it to [default]\nlog_level="normal" in master, the app immediately quits with no error message, as if it had aborted on a non-allowed value in the toml. (docs/guide/10-configuration.md continues, in master, to describe "normal" as an allowed value and in fact the default value in debug mode).
Test Case
Here is a sample project I made: https://codeberg.org/mcc/rocket-hello
To run it, try:
(cd client && npm install) && (cd client && npx webpack) && cargo run -p rkth-server
Running with git commit 17c58e7cffc98fa, this uses 0.5.1. To run this same example with newest master, edit server/Cargo.toml and replace the rocket line with
rocket = { git = "https://github.com/rwf2/Rocket", rev = "3a54d079aef", default-features=false, features = ["json"] }
Log Output
$ ROCKET_LOG_LEVEL=debug cargo run -p rkth-server
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.17s
Running `target/debug/rkth-server`...And that's literally it
Additional Context
I understand master branch is not necessarily supported, but I am developing an application which depends on PR #2970 and 2970 rests atop master, so this is severely impacting my development. master has been in this state since at least last October.
System Checks
- My bug report relates to functionality.
- I have tested against the latest Rocket release or a recent git commit.
- I have tested against the latest stable
rustctoolchain. - I was unable to find this issue previously reported.
Activity
mcclure commentedon Aug 14, 2026
Running git bisect it appears this was broken in ff6da90 .
This commit one of a series of commits, completing around cc2b159 which contains the feature documentation, migrating to the
tracingcrate. I don't think there's a PR associated.The problem I was seeing is that logging no longer works unless the
tracefeature is enabled. This is enabled by default, but I disabled default-features because my configuration does not need HTTP2. If I add thetracefeature, my logging works again.My problem is now resolved. I don't know if there's anything Rocket should do differently here. The only thing I guess I can say is you really need to be very clear in the release notes around your next release that everyone using no-default-features must enable a
tracefeature to get equivalent behavior to 0.5.1.Additionally, since the goal of these changes seems to be Rocket should behave "normally" for a Rust crate, it seems awkward that a malformed Rocket.toml (e.g.:
log_level=debugis a panic,rocket.mountdoes not return) is treated differently from a Rocket.toml which is valid but has malformed keys (e.g.:log_level="bgeoifawg"aborts cleanly at a later time, presumably this is recoverable somehow).[-]All logging and command line error messages are totally broken in master[/-][+]All logging and command line error messages are totally broken in master ["solved"][/+]mcclure commentedon Aug 14, 2026
Two additional thoughts:
I fix some post-Tracing inaccuracies in the docs in PR Correct docs to reflect new log_level names in post-tracing Rocket #3007.
Say that
Rocketis built withouttracing, and the user explicitly setslog_levelto something other than "off". Should this be treated as an error, and the webserver refuse to boot, the way it would iflog_levelwere set to "agohewafoijaew"? Or perhaps, shouldRocketviolate the tracing contract and print directly to STDERR "Warning: User requested a log_level, but tracing is fully disabled in this build"?The problem currently is if the user accidentally themselves in the Bad Place I put myself in above, they are in an error condition ("requested tracing, but tracing is disabled") but they have no way of finding this out, because the error condition suppresses reports about error conditions.
SergioBenitez commentedon Oct 23, 2026
As indicated, you must enable
trace. I will review the PR separately.mcclure commentedon Oct 23, 2026
Thank you for continuing to maintain this, and I am happy to see the project continue at its present slow pace instead of suddenly switching to high churn and a CLAUDE.md