>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3579406. --> Reported by: [dpi](https://www.drupal.org/user/81431) Related to !66 !56 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Implement <code>messenger:stop-workers</code> command so sites may choose to restart workers after a container has been rebuilt.</p> <p>When implementing a new message+handler combination, the handler needs to be discovered and added to the container. If workers are brought up before a full drush deploy with the new changes have been built, then the worker will not have a known handler when a message is sent. This is exposed as </p> <blockquote><p>No handler for message My\Message\Class</p></blockquote> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>We should implement the stop-workers command so sites can set up `drush deploy &amp;&amp; sm messenger:stop-workers` so existing workers are spun down safely and new workers may be spun up by the platform.</p> <p><a href="https://symfony.com/doc/current/messenger.html#deploying-to-production">https://symfony.com/doc/current/messenger.html#deploying-to-production</a></p> <blockquote><p>Restart Workers on Deploy<br> Each time you deploy, you'll need to restart all your worker processes so that they see the newly deployed code. To do this, run messenger:stop-workers on deployment. This will signal to each worker that it should finish the message it's currently handling and should shut down gracefully. Then, the process manager will create new worker processes. The command uses the app cache internally - so make sure this is configured to use an adapter you like. </p></blockquote> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <h3 id="summary-ui-changes">User interface changes</h3> <h3 id="summary-api-changes">API changes</h3> <h3 id="summary-data-model-changes">Data model changes</h3>