Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Behavior changed with messenger:consume and signals #52077

Copy link
Copy link
Closed
@hlecorche

Description

@hlecorche
Issue body actions

Symfony version(s) affected

6.3.5 and 6.3-dev

Description

Since version 6.3.5, there is a compatibility break with the messenger:consume command and signals.

  • After : If SIGINT or SIGTERM signals were sent, the worker stopped AFTER processing the current message
  • Now (6.3.5 and 6.3-dev) : If SIGINT or SIGTERM signals are sent, the worker stops immediately even if a message is being processed (hard stop)

Here are some issues with this change :

  • If Supervisor is used, the supervisorctl stop xxx command can stop the worker before the processing of the current message is completed (hard stop).
  • I'm using the Symfony\Component\Messenger\Event\WorkerMessageFailedEvent event to catch an error. If an error is encountered, the listener stops the task group with Supervisor (with its API and SIGTERM) and sends an email. Now when the event calls the Supervisor API to stop, all actions performed after its call are no longer performed:
    • The email is no longer sent
    • Retry strategy does not work
    • Message processing was stopped abruptly

Link with #50787 ?

How to reproduce

Repository :

Commands :

  • Execute the command php bin/console doctrine:database:create && php bin/console doctrine:schema:update --force
  • Execute the command php bin/console app:create-message && php bin/console messenger:consume async -vvv
  • Send SIGTERM signal

After (< 6.3.5) :

php bin/console  app:create-message && php bin/console messenger:consume async -vvv

                                                                                                                        
 [OK] Consuming messages from transport "async".                                                                        
                                                                                                                        

 // The worker will automatically exit once it has received a stop signal via the messenger:stop-workers command.       

 // Quit the worker with CONTROL-C.                                                                                     

[info] Received message App\Messenger\Message\MessageSuccess
[info] Received signal 15.
[info] Stopping worker.
^ "The worker will stop correctly"
[info] Message App\Messenger\Message\MessageSuccess handled by App\Messenger\MessageHandler\MessageSuccessHandler::__invoke
[info] App\Messenger\Message\MessageSuccess was handled successfully (acknowledging to transport).

Now (6.3.5 and 6.3-dev) :


php bin/console  app:create-message && php bin/console messenger:consume async -vvv

                                                                                                                        
 [OK] Consuming messages from transport "async".                                                                        
                                                                                                                        

 // The worker will automatically exit once it has received a stop signal via the messenger:stop-workers command.       

 // Quit the worker with CONTROL-C.                                                                                     

[info] Received message App\Messenger\Message\MessageSuccess
[info] Received signal 15.
[info] Stopping worker.

Possible Solution

No response

Additional Context

When I did my tests, pcntl was enabled (echo \SIGINT; returns 2)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Morty Proxy This is a proxified and sanitized view of the page, visit original site.