Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[Console][DI] Fail gracefully#25255
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
2aae22b tod4b6c01Compare2cdb49b toc4d43f7Comparetheofidry commentedDec 1, 2017
@nicolas-grekas so you would still get a silent hard failure if you do |
nicolas-grekas commentedDec 1, 2017
Not since 10 minutes. When did you read the code ? :) |
theofidry commentedDec 1, 2017
I didn't, but I have trouble following :P |
weaverryan commentedDec 1, 2017
Fwiw, I believe a user on Twitter hit the same issue - when removing Twighttps://twitter.com/neelion333/status/936623941937795072 - looks very easy to reproduce |
weaverryan commentedDec 2, 2017
I think this bug might be quite critical. I think I'm even able to hit it through the web interface. While upgrading a project from 3.3 to 3.4, I did the following:
@nicolas-grekas Do you think it's related? Do you need me to try to create a repeater (the above was done on our big KnpU Symfony 3 tutorial project). |
cb4b9ee tob8bd1f0Compareb8bd1f0 to4a5a3f5Comparenicolas-grekas commentedDec 2, 2017
@weaverryan looks like the same yes. I improved the behavior by replacing the nasty PR is ready. Dunno how to test it as the behavior is triggered by edge case fatal errors... |
fabpot commentedDec 2, 2017
Thank you@nicolas-grekas. |
This PR was merged into the 3.4 branch.Discussion----------[Console][DI] Fail gracefully| Q | A| ------------- | ---| Branch? | 3.4| Bug fix? | yes| New feature? | no| BC breaks? | no| Deprecations? | no| Tests pass? | yes| Fixed tickets |symfony/flex#212,#25280| License | MIT| Doc PR | -I already experienced this issue a few times without spending time digging it:sometimes, you call `cache:clear`, and the command quits without any output, and with 255 status code.The reason is the `@include` in `Kernel`, which makes everything silent, especially fatal errors (thanks PHP...)So if the to-be-removed container is broken for some fatal reason, the failure is really bad.To fix that, here are two measures:- use `include_once` instead of `require_once` in the dumped container: that's OK there to actually not immediately load the file, any hard failure will happen later anyway, and any soft failure will allow the `cache:clear` command to complete (like when you remove a package)- register `Application::renderException()` as the main PHP exception handler, via `Debug::ErrorHandler` when it's availableEnd result when it fails:instead of a blank output.Commits-------4a5a3f5 [Console][DI] Fail gracefully
weaverryan commentedDec 3, 2017
I do not appear to be able to trigger the fatal error anymore. I think you may have gotten it! |
…nclude_once (nicolas-grekas)This PR was merged into the 3.4 branch.Discussion----------[DI] Fix initialization of legacy containers by delaying include_once| Q | A| ------------- | ---| Branch? | 3.4| Bug fix? | yes| New feature? | no| BC breaks? | no| Deprecations? | no| Tests pass? | yes| Fixed tickets | -| License | MIT| Doc PR | -Best reviewed ignoring whitespaces:https://github.com/symfony/symfony/pull/25858/files?w=1Noticed while removing a package: silencing the failing `include_once` as introduced in#25255 is not working for the `$oldContainer` in `Kernel`, and fails with a fatal error when an include succeeds but the class inside misses a parent.Delaying the calls to `include_once` to the moment where the fresh container is actually used first, when setting the "kernel" service, works around the situation.Commits-------5e750ec [DI] Fix initialization of legacy containers by delaying include_once
k00ni commentedMar 16, 2018 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
I experienced this bug today usingSymfony 4.0.6. It occurs in certain controller actions and not when using the cache commands via terminal. But these actions call indirectly
Afterwards i cleared the cache using EDIT: See#25255 (comment) for updates to the WebProfilerBundle. |
nicolas-grekas commentedMar 16, 2018
What are you calling in your controller? |
k00ni commentedMar 16, 2018 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Here is part of the code: $env =/* .. */;$cache =newFilesystemCache('',0,__DIR__.'/../../var/cache/'.$env);// do some mysql operations$cache->clear(); I expected the cache, because you mentioned it at the beginning. Furthermore, it tried to load something from the cache folder, which could not be opened.
|
k00ni commentedMar 16, 2018
Ok, i changed |
nicolas-grekas commentedMar 16, 2018
I suppose. FilesystemCache is not made for clearing the full Symfony cache AFAIK. |

Uh oh!
There was an error while loading.Please reload this page.
I already experienced this issue a few times without spending time digging it:
sometimes, you call
cache:clear, and the command quits without any output, and with 255 status code.The reason is the
@includeinKernel, which makes everything silent, especially fatal errors (thanks PHP...)So if the to-be-removed container is broken for some fatal reason, the failure is really bad.
To fix that, here are two measures:
include_onceinstead ofrequire_oncein the dumped container: that's OK there to actually not immediately load the file, any hard failure will happen later anyway, and any soft failure will allow thecache:clearcommand to complete (like when you remove a package)Application::renderException()as the main PHP exception handler, viaDebug::ErrorHandlerwhen it's availableEnd result when it fails:

instead of a blank output.