class_alias calls not available when rebuilding container in ModuleInstaller

Do a clean site install from configuration: drush si --existing-config

I wouldn't call that a "clean site installation". This is installing a new site from existing config, which can contain all sort of stuff, which is not a clean Drupal 10.2 installation.

The circular reference you experience here might be a follow-up error from the first one, which is this:

Error: Class "Drupal\variationcache\Cache\VariationCacheFactory" not found in Drupal\Component\DependencyInjection\Container->createService() (line 259 of /REDACTED/core/lib/Drupal/Component/DependencyInjection/Container.php) #0 /REDACTED/core/lib/Drupal/Component/DependencyInjection/Container.php(177): Drupal\Component\DependencyInjection\Container->createService(Array, 'variation_cache...')

I've looked into that module variationcache which defines the services variation_cache_factory. That is part of the circular reference that's being reported, but the class that service is referring to, doesn't exist. It's defined as a class alias in a module file that's not yet loaded when services get initialized.

You may want to try without that variationcache module or ask there, if that can be fixed somehow.

From module installer:

        // Update the kernel to include it.
        $this->updateKernel($module_filenames);

        // Load the module's .module and .install files.
        $this->moduleHandler->load($module);
        $this->moduleHandler->loadInclude($module, 'install');

So it should include variationcache.module and therefore find the class_alias calls, but instead it first tries to read the services files and then loads the module and install file, which is too late. So this might be a core bug we're looking at.

Having said that, I'm curious as to why this doesn't fail with clean Group installs and does with ECA.

I think I see what's happening.

ECA subscribes to kernel events, which are fired during container build. This leads to a series of dependencies ending up at variation_cache_factory, which since core 10.2 exists both in core.services.yml and variationcache.services.yml, with the latter counting as a decorator.

The contrib module's services file is found before the module file is enabled and normally that would be okay because the service does not get initialized during the module's install. But because of the event subscriber trying to initialize it through its dependencies and the class_alias call not being declared yet, it fails.

We can fix this in core by first including the module and install file and then rebuilding the container, or we can fix this in VC by using a ServiceProvider to declare the service only when core's variation_cache_factory service does not exist (i.e. you're on core < 10.2). Given how this might occur for more than just VC, I'm inclined to aim for a fix in core.

class_alias is actively encouraged in core to work around BC breaks, so I'd expect the module installer to support this.

Drupal\Tests\system\Functional\Module\ClassLoaderTest::testAutoloadFromModuleFile fails, output (from the artifacts):

The website encountered an unexpected error. Try again later.

Error: Class "Drupal\module_autoload_test\SomeClass" not found in include_once() (line 10 of core/modules/system/tests/modules/module_autoload_test/module_autoload_test.module).

Drupal\Core\Extension\Extension->load() (Line: 128)
Drupal\Core\Extension\ModuleHandler->load('module_autoload_test') (Line: 251)
Drupal\Core\Extension\ModuleInstaller->install(Array, 1) (Line: 83)
Drupal\Core\ProxyClass\Extension\ModuleInstaller->install(Array) (Line: 502)
Drupal\system\Form\ModulesListForm->submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 597)
Drupal\Core\Form\FormBuilder->processForm('system_modules', Array, Object) (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 37)
Drupal\Core\Test\StackMiddleware\TestWaitTerminateMiddleware->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Digging deeper

Ugh, so swapping the code around means the module file is included before updateKernel is called, which in turn calls $this->kernel->updateModules($module_filenames, $module_filenames); where the namespaces are registered and the container is rebuilt. The fact that the namespaces aren't registered yet makes that test fail.

If we want to fix this in core, we'd need to tear this code apart and first register namespaces, then include module/install file and only then rebuild the container.

I'm starting to think this is a lot of work for an absolute edge case, the conditions are as follows:

1. Module A has an event subscriber to kernel events
2. Said event subscriber has a few core services as dependencies
3. Module B is installed and decorates one of these core services with a class aliased class
4. The class_alias call is inside Module B's .module file, which hasn't been loaded at the time the kernel event subscriber is called

Ideally, this is fixed in core as we claim to support class_alias but clearly don't, but the work required might be out of proportion compared to how rare this bug is and how comparatively easy it is perhaps to fix in module B (contrib VariationCache).

Will drop this in Drupal Slack and ask for more opinions.

A simple way to test this is to write a test module that has:

1. A class in the src folder
2. A class_alias to said class in the module file
3. An EventSubscriber to kernel events in the services.yml file using the alias for the class

Trying to install that module should fail as it registers an at-the-time non-existent class alias and tries to instantiate that service (as it's an event subscriber and kernel events are fired), leading to a class not found exception.

@jurgenhaas Try the patch here please: #3414766-2: Resolve edge case where kernel event subscribers crash because class aliases aren't defined yet →

If someone gets this error for a stand-alone CLI script. The quick solution (for me) was:

\Drupal::moduleHandler()->load('variationcache');

after $kernel->boot();

Hope this is helpful for some.