Refactoring hux services breaks container rebuild

One option can be to return the decorated (core) module handler as a fallback.

We can do this kind of contraption. But I would really prefer something simpler.

  public static function createOrFallback(
    ContainerInterface $container,
    ModuleHandlerInterface $fallbackModuleHandler,
    string $huxModuleHandlerServiceId,
    string|int $huxContainerVersion,
  ): ModuleHandlerInterface {
    if ((string) $huxContainerVersion !== '2') {
      // Container is out of date.
      # \Drupal::service('kernel')->invalidateContainer();
      return $fallbackModuleHandler;
    }
    // Container is up to date. Get the real Hux module handler.
    $module_handler = $container->get($huxModuleHandlerServiceId);
    assert($module_handler instanceof ModuleHandlerInterface);
    return $module_handler;
  }

  hux.module_handler:
    decorates: module_handler
    class: Drupal\hux\HuxModuleHandler2
    public: true
    arguments:
      - '@hux.module_handler.inner'
      - '@hux.map'
    calls:
      - [ setContainer, [ '@service_container' ] ]
  hux.module_handler_or_fallback:
    decorates: module_handler
    class: Drupal\Core\Extension\ModuleHandlerInterface
    factory: [ Drupal\hux\HuxModuleHandler, 'createOrFallback' ]
    public: true
    arguments:
      - '@service_container'
      # The fallback module handler is the "decorated" object from the other decorator..
      - '@hux.module_handler.inner'
      - 'hux.module_handler_or_fallback.inner'
      - '%hux.container_version%'

So the idea would be to have the "hux.module_handler_or_fallback" service, which would never change, but we are free to change any other services below that.

So, we are using a "fake decorator" that does not actually wrap its own class around the decorated value, but instead returns either the original value, or something else.

#3153335: Document $settings['deployment_identifier'] (and that it fixes moved class autoloader caching) →

Couldnt reproduce.

Changed Classname + File name + updated reference in service.yml.

No errors on `drush cr`, and Hux hooks continued to work.

This is with stock Hux + Drupal 10.1 + fresh site install + only one Hux hook implementation.

Posting stack:

Closing as cant repro, feel free to reopen with more specific steps to repro, or alternative setup/enviro.

Now I cannot reproduce it either. Strange.
I will get back to it when I have more time.

I found it!
The problem occurs when I use drush/drush:12.1.0, but not with drush/drush:11.6.0.
It seems that drush 12 does a more complete bootstrap before it runs the command.