Skip to content

Unable to use the proper exit code #1096

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

Closed
gnumoksha opened this issue Sep 29, 2020 · 3 comments
Closed

Unable to use the proper exit code #1096

gnumoksha opened this issue Sep 29, 2020 · 3 comments
Labels

Comments

@gnumoksha
Copy link
Contributor

Scenario

I've custom commands to consume messages and I'm using ExitStatusExtension like in ConsumeCommand. $exitStatusExtension->getExitStatus() is the primary way to return the command's exit code.

Issue

It seems no built-in extension (e.g. SignalExtension, LimitConsumedMessagesExtension) does implement the necessary code to return the exit status because $context->interruptExecution() is always called without arguments.

The correct return code will be very useful to inform to the process manager (e.g. supervisord, systemd) to restart the consumer or not. Example: one might want to restart the consumer if LimitConsumerMemoryExtension stopped the consumption, but he might not want to restart if SignalExtension stopped the consumption.

@gnumoksha
Copy link
Contributor Author

The exit status feature was introduced in #766

@gnumoksha
Copy link
Contributor Author

I think this feature will need a study in order to set default exit codes. An example would be analyzing some well-know commands and see what is the exit code they return when stopped via signal (e.g. control + c).

If my understanding is right, this feature will also introduce a breaking change because users of this library either don't expect exit codes (other than 0) or have their own logic to return the exit codes.

I can work on this.

@stale
Copy link

stale bot commented Nov 5, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Nov 5, 2020
@stale stale bot closed this as completed Nov 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant