>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3579407. --> Reported by: [dpi](https://www.drupal.org/user/81431) Related to !68 !67 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <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><del>We should be able to automate triggering stop-workers signals (perhaps opt-in/out) when we detect a container rebuild has happened. Perhaps using cache tags, or the container cache key (<code>\Drupal\Core\DrupalKernel::getContainerCacheKey</code>).</del></p> <p>The implementation adds a listener to which the worker dispatches events.</p> <p>The listener sets a cache item in our cache bin on start.</p> <p>Each time the event is received, the listener checks if the cache item still exists.</p> <p>If it no longer exists, then it quits.</p> <p>The cache bin is reset when drupal caches are cleared.</p> <p>According to the logic of \drupal_flush_all_caches()</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <h3 id="summary-ui-changes">User interface changes</h3> <p>None</p> <h3 id="summary-api-changes">API changes</h3> <p>Maybe</p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>None</p> > Related issue: [Issue #3579406](https://www.drupal.org/node/3579406)