-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
Error logs are silently lost if LogPlugin
is added late.
#13409
Comments
Ultimately caused by #1255. We need real plugin ordering in some form to avoid this sort of footgun. |
The following gives an App::new().init_state::<Foo>(); However, None of the approaches suggested in this issue would solve this case. It may be worth considering setting up logging in |
I like the idea of adding it in |
Actually you're right. bevy/crates/bevy_app/src/app.rs Lines 92 to 114 in a0f5ea0
|
The problem is that |
Problem
Perfectly good error logs are silently lost if
DefaultPlugins
orLogPlugin
has not been added early enough.I found this behavior on the main branch but I expect it goes pretty far back.
Example
I was mucking around with mesh2d_manual for reasons and I made this mistake: I put
ExtractResourcePlugin
ahead ofDefaultPlugins
.I was befuddled by this because I could see the error message in the code and assumed I must not be hitting that execution path. I added some
eprintln!
and figured out it was theLogPlugin
that needed to come first before the error was reported. To provoke the error again and log it, I addedLogPlugin
manually.This then showed me the right error message:
This is a great error message and would have set me straight if I had seen it.
Suggested Solutions
Fix in the small
One could have
ExtractResourcePlugin
come beforeDefaultPlugins
if it did its work infinish()
rather thanbuild()
. I've seen a few plugins opt for this when dealing with theRenderApp
. Maybe that should be done but I think that's avoiding a larger issue.Accumulate Log Counts
Perhaps errors emitted before
LogPlugin
ought to be accumulated somehow so they aren't silently lost untilLogPlugin
is added. Keeping an accounting of the missing log types would be helpful. Then whenLogPlugin
is added, it could emit this warning if there are missing log types that we care about:Maybe a
LogCountPlugin
could be devised that only collects those counts.And if the
App
never addsLogPlugin
, maybe those counts could be made available somewhere.Conclusion
I'm happy to submit a PR for either of these solutions if desired.
The text was updated successfully, but these errors were encountered: