[Console] Suppress unhandled error in some specific use-cases. #46291
Conversation
|
Hey! I see that this is your first PR. That is great! Welcome! Symfony has a contribution guide which I suggest you to read. In short:
Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change. When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor! I am going to sit back now and wait for the reviews. Cheers! Carsonbot |
|
Hey! I think @dkarlovi has recently worked with this code. Maybe they can help review this? Cheers! Carsonbot |
|
@rw4lll reading the related Laravel issue, you mention this happens when the command is invoked in web context? That should basically never happen. If it does, it should be up to the invoker (I guess, Artisan?) to handle these issues on its side, maybe by introducing a custom error handler or similar? In any case, I'm 👎 here. |
There was a problem hiding this comment.
Hi. Thanks for the PR.
Given this is a default command, and configure() is called automatically when instantiating the Application, I agree that suppressing the error is the best way forward. Otherwise, any user of the Console component will have this error when using open_basedir.
For reference, Symfony overrides the Application class from the component in the FrameworkBundle and uses lazy loading of all commands. This means that in a Symfony application, configure() is only called when the command is called. This means that it is indeed unlikely to get this error when using the Symfony full-stack framework.
|
Thank you @rw4lll. |
If the package is used not in console with open_basedir enabled, since 5.4 it fails with unhandled php error here:
(https://github.com/symfony/console/blob/06974380c667d7d8e3cd0f24bf51f816a71ca6c6/Command/DumpCompletionCommand.php#L44) because of trying to call realpath("/") and, of course, it's not allowed.
It's a very specific use-case for Symfony, but can happen if it's used as dependency, e.g. in Laravel. I've described it in details here: laravel/framework#42171
I think that the best would be just suppress the error in that case.