Regression: All stack middlewares are constructed at the same time even for cached pages

I guess this could be solved with a service closure for the $http_kernel argument in PageCache middleware.

Added a draft MR. This prevents the event dispatcher from being instantiated when a page is delivered from the cache.

Setting to NR for early feedback. This still needs tests for the deprecation in the page cache middleware. I think we should deprecate the responder tag attribute as well. This could be done in a follow-up though.

I do not know what happened to lazy services since #2473113: All stack middlewares are constructed at the same time even for cached pages. They are being removed gradually anyway, so didn't bother to look.

And if it doesn't, should the code setting that up be removed?

Yes. In a follow-up.

Went through an epic git bisect only to find that this broke just two months after it was introduced. Everything happened before 8.0 was even released.

Lazy middlewares and responder tag introduced in: #2473113-47: All stack middlewares are constructed at the same time even for cached pages commit date: 2015-04-30

Lazy middlewares and responder tag broken by: #2408371-83: Proxies of module interfaces don't work commit date: 2015-06-30

#2408371: Proxies of module interfaces don't work introduced ProxyServicesPass. But that runs before StackedKernelPass. So the lazy flag added StackedKernelPass to middleware definitions on top of the first responder has no effect.

I tried to move the StackedKernelPass before ProxyServicesPass.

diff --git a/core/lib/Drupal/Core/CoreServiceProvider.php b/core/lib/Drupal/Core/CoreServiceProvider.php
index cd9766c14b5..26cab2964e6 100644
--- a/core/lib/Drupal/Core/CoreServiceProvider.php
+++ b/core/lib/Drupal/Core/CoreServiceProvider.php
@@ -73,14 +73,14 @@ public function register(ContainerBuilder $container) {

     $container->addCompilerPass(new SuperUserAccessPolicyPass());

+    $container->addCompilerPass(new StackedKernelPass());
+
     $container->addCompilerPass(new ProxyServicesPass());

     $container->addCompilerPass(new BackendCompilerPass());

     $container->addCompilerPass(new CorsCompilerPass());

-    $container->addCompilerPass(new StackedKernelPass());
-
     $container->addCompilerPass(new StackedSessionHandlerPass());

     $container->addCompilerPass(new MainContentRenderersPass());

But ProxyServicesPass doesn't like that:

[warning] Missing proxy class 'Symfony\Component\ProxyClass\HttpKernel\HttpKernel' for lazy service 'http_kernel.basic'.
Use the following command to generate the proxy class:
  php core/scripts/generate-proxy-class.php 'Symfony\Component\HttpKernel\HttpKernel' "[namespace_root_path]"

ProxyServicesPass.php:63

Besides the HttpKernel, the following middleware classes are reported:

• Drupal\Core\ProxyClass\StackMiddleware\ContentLength
• Drupal\Core\ProxyClass\StackMiddleware\KernelPreHandle
• Drupal\Core\ProxyClass\StackMiddleware\Session
• Drupal\big_pipe\ProxyClass\StackMiddleware\ContentLength

There are for sure more missing in contrib and custom code. Thus, trying to fix the lazyness is not an option I guess.

The CR is a stub. Help welcome.

Performance (Drupal core standard install)

Software:

% uname -v
#1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22)

% php -v
PHP 8.3.23 (cli) (built: Jul  3 2025 16:20:45) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.23, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.23, Copyright (c), by Zend Technologies
    with Xdebug v3.4.4, Copyright (c) 2002-2025, by Derick Rethans

% podman ps
CONTAINER ID  IMAGE                          COMMAND     CREATED        STATUS            PORTS       NAMES
2967cbf5773c  docker.io/library/postgres:16  postgres    4 minutes ago  Up 4 minutes ago              drupal_memory

Webserver:

% export PHP_CLI_SERVER_WORKERS=4
% php -S localhost:8888

Core baseline:

% composer create-project --no-interaction "drupal/recommended-project:^11.x-dev" core-dev
# Install core standard profile
# Disable css/js aggregation (not compatible with php built-in webbrowser)
# Add node/1
# Rebuild container, clear caches, warm cache
% ab -c 1 -n 500 http://localhost:8888/node/1 > ./core-dev-baseline.txt

Requests per second:    44.61 [#/sec] (mean)
Time per request:       22.415 [ms] (mean)
Time per request:       22.415 [ms] (mean, across all concurrent requests)

Core + patch:

% patch -p1 < /tmp/perf.patch
% # Rebuild container, clear caches, warm cache
% ab -c 1 -n 500 http://localhost:8888/node/1 > ./core-dev-patched.txt

Requests per second:    55.61 [#/sec] (mean)
Time per request:       17.984 [ms] (mean)
Time per request:       17.984 [ms] (mean, across all concurrent requests)

Drupal CMS baseline:

% composer create-project --no-interaction "drupal/cms:^1.2.x-dev" cms-dev
# Enable some recipes. I had to disable case management and project management due to field storage issues..
# Disable css/js aggregation (not compatible with php built-in webbrowser)
# Rebuild container, clear caches, warm cache
% ab -c 1 -n 500 http://localhost:8888/ > ./cms-dev-baseline.txt

Requests per second:    29.76 [#/sec] (mean)
Time per request:       33.597 [ms] (mean)
Time per request:       33.597 [ms] (mean, across all concurrent requests)

Drupal CMS + patch:

% patch -p1 < /tmp/perf.patch
% # Rebuild container, clear caches, warm cache
% ab -c 1 -n 500 http://localhost:8888/ > ./cms-dev-patched.txt

Requests per second:    44.32 [#/sec] (mean)
Time per request:       22.563 [ms] (mean)
Time per request:       22.563 [ms] (mean, across all concurrent requests)

(forgot to attach raw data)

The failure of UncaughtExceptionTest::testLoggerException() is interesting. This test examines the PHP error.log in order to check whether exceptions get logged when the normal logger failed.

https://git.drupalcode.org/issue/drupal-3538294/-/pipelines/560646/test_...

Drupal\FunctionalTests\Bootstrap\UncaughtExceptionTest::testLoggerException
The error + the error that the logging service is broken has been written to the error log.
Failed asserting that actual size 12 matches expected size 10.

core/tests/Drupal/FunctionalTests/Bootstrap/UncaughtExceptionTest.php:251

I reproduced it locally and found that NegotiationMiddleware appears in the stack trace with the patch, but doesn't on the 11.x branch. The reason is that MonkeysInTheControlRoom middleware is registered with the same priority. But since PriorityTaggedServiceTrait::findAndSortTaggedServices() uses a different method of sorting, the middlewares swapped their location in the stack.

Bumped the monkey middleware to an appropriate priority to solve the test fail (404).

I think the dates in #12 should be 2015 rather than 2026?

Thanks, fixed.

Would a service locator be an option here instead of the lazy services pass? We've been switching to those in #3483996: Remove lazy declaration and proxy class for cron and use service closure instead: Remove lazy declaration and proxy class for cron and use service closure instead and similar issues.

I haven't looked into service locators. The cited issue is using service closures (same tech as the PR). Lazy services are not part of the fix (the dysfunctional lazy flagging is removed in this PR).

As for the question whether it would be possible to do this without a custom service pass: I do not yet know. The service pass has two responsibilities: Assemble every service tagged with http_middleware into a stack. This is done by prepending a reference to the decorated service to the arguments array of the decorator. The second responsibility is to inject all discovered middlewares into the StackedHttpKernel. This is required to propagate the terminate call. Maybe the symfony container provides all the necessary tooling to realize that. But even then, it would be necessary to add some kind of BC pass to move old declarations (tagged with http_middleware to their spot in the stack. I'd be interested to explore. Not sure whether this should be done in this issue or in a follow-up.

CR is ready. Also pushed an update to the StackedKernelPass docs.

I pushed a test which asserts that http_kernel.basic is not initialized when http_kernel is retrieved from the container.

Also rebased and converted phpunit annotations to attributes.