-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Console] Add support for managing exit code while handling signals #49529
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
Conversation
4725a83
to
af0f5fe
Compare
af0f5fe
to
fd64a13
Compare
This was the BC-break I referred to when I brought up the initial issue 😅 @lyrixx thanks for your work here, there are indeed many factors to take into account when tweaking signal handling. For my use case, the solution will work fine. It feels a bit cumbersome to modify the event state buuuut it's fine. It's really important to document the nuances and what's expected from each different use case 👍 |
Yes, it's not so cool to have to edit the event, but we must do it since we cannot now if the end user will stop / exit / return itself. So by default we should mimic PHP, and the user can opt-in for managing exit themself. |
a24c7e8
to
3091710
Compare
@lyrixx You can rebase this one (I've merged up the other 2 PRs). |
47aee88
to
35ccc92
Compare
Rebase ✅ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 for this. The CHANGELOG should mention the BC break though
What bc break are you talking about? The new method in the interface? I should update the upgrade.md too! |
Yes! |
35ccc92
to
f4fe1c1
Compare
Fixed |
This comment was marked as resolved.
This comment was marked as resolved.
f4fe1c1
to
09dbb75
Compare
Thanks for the review! I pushed a new version without the new method on the interface! The new API is even simpler! |
4c56899
to
392f0ff
Compare
039c1a6
to
e0b43d2
Compare
getExitCode()
method to SignalableCommandInterface
e0b43d2
to
3bbe3d1
Compare
3bbe3d1
to
14a4f48
Compare
src/Symfony/Component/Console/Tests/SignalRegistry/SignalRegistryTest.php
Outdated
Show resolved
Hide resolved
14a4f48
to
dab0517
Compare
dab0517
to
1650e38
Compare
getExitCode()
method to SignalableCommandInterface
Thank you @lyrixx. |
Signal handling is hard! This commit fixes an issue introduced in bb7779d, see this comment for more information.
Symfony registers by default 4 signals, the most common ones:
SIGINT
,SIGTERM
,SIGUSR1
, andSIGUSR2
.When no signal handler are registered, the default behavior is to stop the
execution of the current script, to replication PHP default behavior.
That's why we had a call to exit(0), before
bb7779d and that's why it must be restored.
However, the concerns raised in the
issue are valid, and we
should provided a solution for this.
Now we have the following features:
SIGINT
,SIGTERM
;$event->abortExit()
;$event->setExitCode($code)
;SignalableCommandInterface
to tell via the command tonot exit, by returning
int|false
fromhandleSignal()
methodI think we have all we need now. I added more tests to ensure we don't break
anything in the future.
Sorry for the massive ping here, but this is bit like an a house of cards to
make it work in any case. I hope I didn't miss anything.
ping @akuzia @lcobucci @GromNaN @olegpro