Update to Symfony 6.4.8 throws error

I can confirm that our team experiences this error, too, with Drupal 10.2.6 (which has a requirement on symfony ^6.4, which will result in retrieving symfony libraries version 6.4.8.

A short-term site-specific workaround is to declare a conflict as shown below:

  "conflict": {
    "symfony/yaml":"6.4.8",
    "symfony/validator":"6.4.8",
    "symfony/string":"6.4.8",
    "symfony/serializer":"6.4.8",
    "symfony/psr-http-message-bridge":"6.4.8",
    "symfony/process":"6.4.8",
    "symfony/mime":"6.4.8",
    "symfony/mailer":"6.4.8",
    "symfony/intl":"6.4.8",
    "symfony/http-kernel":"6.4.8",
    "symfony/http-foundation":"6.4.8",
    "symfony/error-handler":"6.4.8",
    "symfony/dependency-injection":"6.4.8",
    "symfony/console":"6.4.8",
    "symfony/config":"6.4.8",
    "symfony/cache":"6.4.8",
    "symfony/var-exporter":"6.4.8",
    "symfony/var-dumper":"6.4.8",
    "symfony/routing":"6.4.8",
    "symfony/framework-bundle":"6.4.8",
    "symfony/finder":"6.4.8",
    "symfony/filesystem":"6.4.8",
    "symfony/event-dispatcher":"6.4.8"
  },
<code>

However, the longer term fix is going to be in the <code>simplesamlphp

library itself. In other words, based on the stacktrace this doesn't appear to be coming from the Drupal module simplesamlphp_auth

I believe the code change responsible for this is shown at https://github.com/symfony/framework-bundle/compare/v6.4.8...6.4

See https://github.com/symfony/symfony/issues/57316 for what appears to be the related issue in the Symfony project queue.

Can confirm this issue when I updated a site to D10.2.7 this afternoon.

SimpleSAML\Error\Error: UNHANDLEDEXCEPTION
Backtrace:
1 src/SimpleSAML/Error/ExceptionHandler.php:32 (SimpleSAML\Error\ExceptionHandler::customExceptionHandler)
0 [builtin] (N/A)
Caused by: Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "serializer.normalizer.object".
Backtrace:
11 /code/vendor/symfony/dependency-injection/ContainerBuilder.php:992 (Symfony\Component\DependencyInjection\ContainerBuilder::getDefinition)
10 /code/vendor/symfony/framework-bundle/DependencyInjection/FrameworkExtension.php:1999 (Symfony\Bundle\FrameworkBundle\DependencyInjection\FrameworkExtension::registerSerializerConfiguration)
9 /code/vendor/symfony/framework-bundle/DependencyInjection/FrameworkExtension.php:389 (Symfony\Bundle\FrameworkBundle\DependencyInjection\FrameworkExtension::load)
8 /code/vendor/symfony/dependency-injection/Compiler/MergeExtensionConfigurationPass.php:76 (Symfony\Component\DependencyInjection\Compiler\MergeExtensionConfigurationPass::process)
7 /code/vendor/symfony/http-kernel/DependencyInjection/MergeExtensionConfigurationPass.php:42 (Symfony\Component\HttpKernel\DependencyInjection\MergeExtensionConfigurationPass::process)
6 /code/vendor/symfony/dependency-injection/Compiler/Compiler.php:80 (Symfony\Component\DependencyInjection\Compiler\Compiler::compile)
5 /code/vendor/symfony/dependency-injection/ContainerBuilder.php:767 (Symfony\Component\DependencyInjection\ContainerBuilder::compile)
4 /code/vendor/symfony/http-kernel/Kernel.php:506 (Symfony\Component\HttpKernel\Kernel::initializeContainer)
3 /code/vendor/symfony/http-kernel/Kernel.php:763 (Symfony\Component\HttpKernel\Kernel::preBoot)
2 /code/vendor/symfony/http-kernel/Kernel.php:185 (Symfony\Component\HttpKernel\Kernel::handle)
1 src/SimpleSAML/Module.php:234 (SimpleSAML\Module::process)
0 public/module.php:17 (N/A)

That backtrace clearly shows that this is the simpleSAMLphp bootstrap, and not Drupal. I can see that it's being reported in symfony and I guess beig fixed there, but if not, such an error needs to be reported in https://github.com/simplesamlphp/simplesamlphp, not here. Keeping this open as a support request for for visibility, but there's nothing we can do about that here.

@berdir Thanks for that. We did report it to the simplesamlphp maintainers in their Slack workspace, and their response was similar -- this is a Symfony problem, you'll have to wait for a bugfix from them.

Thank you @berdir and @gravelpot. We will pursue inserting the conflict block, and work from there.

Thank you @mark_fullmer for the workaround!

> but there's nothing we can do about that here.

So, that's not entirely true. What we can do is add a conflict with the broken version(s), but not sure we should do that before we know which version the fix will be in. Still, it could be useful to prepare the MR for that and hope the next patch releases will have the fix.

@mark_fullmer

Thank you for your comment stating how to roll back to previous Symfony version.

I agree with @Berdir that

> but there's nothing we can do about that here.

However, I wonder about something:
I experienced this issue on a brand new installation of Simplesamlphp_auth; however, on none of the other 3 other sites -which already had installed this module, I did not experience any issue after updating to Drupal 10.2.7

I wonder why?

@la588 For the sites that are not experiencing this issue, check the `composer.lock` file to see what version of the Symfony libraries it is running. The problem was introduced in Symfony 6.4.8. Because of the way Drupal core specifies its own version requirement for Symfony as `^6.4`, you could have different sites running the same version of Drupal with different versions of the Symfony libraries.

Our sites started exhibiting the problem after an automated `composer update` process updated the sites to Symfony 6.4.8. No Drupal version changes occurred.

My guess is that if you ran `composer update` on the sites you have that are not experiencing the bug, they would update to Symfony 6.4.8 and then they _would_ experience the bug.

Thanks graveplot

I have thought that as well, but I did check all the different symfony packages (23) -as listed above by mark_fullmer, in the 'composer.lock' file, and all of them are set to "version": "v6.4.8"

For example:
"name": "symfony/event-dispatcher",
"version": "v6.4.8",

As an FYI, any new release of drupal/core will create drupal/core-recommended with requirements of symfony at ~v6.4.8. So when 10.3.0 comes out for example (or a new beta), and someone is using drupal/core-recommended, a work around will be to use drupal/core instead and then pin the packages until this gets fixed upstream at simplesaml.

Can confirm all the above and #2 worked for a temp fix so we could update to 10.2.x

For whatever it is worth, I could not simply add the conflict step in #2 and it just work. Composer gave me the following error

Problem 1
- my/project is present at version dev-main and cannot be modified by Composer
- my/project dev-main conflicts with symfony/event-dispatcher v6.4.8.
- symfony/event-dispatcher is locked to version v6.4.8 and an update of this package was not requested.

To get around this I did the following

1. composer require "symfony/yaml":"6.4.8" "symfony/validator":"6.4.7" "symfony/string":"6.4.7" "symfony/serializer":"6.4.7" "symfony/psr-http-message-bridge":"6.4.7" "symfony/process":"6.4.7" "symfony/mime":"6.4.7" "symfony/mailer":"6.4.7" "symfony/intl":"6.4.7" "symfony/http-kernel":"6.4.7" "symfony/http-foundation":"6.4.7" "symfony/error-handler":"6.4.7" "symfony/dependency-injection":"6.4.7" "symfony/console":"6.4.7" "symfony/config":"6.4.7" "symfony/cache":"6.4.7" "symfony/var-exporter":"6.4.7" "symfony/var-dumper":"6.4.7" "symfony/routing":"6.4.7" "symfony/framework-bundle":"6.4.7" "symfony/finder":"6.4.7" "symfony/filesystem":"6.4.7" "symfony/event-dispatcher":"6.4.7"
2. added conflicts to composer.json in #2
3. run composer update --lock
4. remove newly defined symfony dependencies from composer.json
5. rerun composer update --lock

Regarding the upstream PR, it looks like it was merged in and is on the 6.4 branch. Based off a comment in the duplicate GH issue, releases are approximately monthly and should be coming out soon.

@nicholass the https://www.drupal.org/project/simplesamlphp_auth/issues/3452457#comment... 💬 Update to Symfony 6.4.8 throws error Active worked as a temp fix by me.

Can confirm all the above and #2 worked for a temp fix so we could update to 10.2.x

So are we just hoping that symphony 6.4.9 fixes the issue?

I'm waiting for the real fix.

Please see my comment here https://www.drupal.org/project/drupalauth4ssp/issues/3453721#comment-156... 💬 Fatal exception with simplesamlphp 2.2.2: non-existent service "serializer.normalizer.object" Closed: works as designed with a patch that is already released in Symfony 7.1.1.

Temporary workaround , but still.

Thanks @RoSk0 patching symfony/framework-bundle fixes the issue.

Symfony 6.4.9 has been released. Has anyone tried this update yet?

@shelane Its working in 6.4.9 version. I have upgraded from 6.4.7 to 6.4.9 and its working absolutely fine.

@shelane just updated a site to Symfony 6.4.9 on Pantheon, and it's working fine. Note that SimpleSAMLphp is caching the error page: if that happens, try logging in again.

I can also confirm that using symfony/frameworkbundler version 6.4.9 avoids the problem introduced in 6.4.8.

I also observed an error, as reported in #22, the first time attempting to sign in, which stopped happening on subsequent attempts. I'm not convicnce that it is "SimpleSAMLphp caching the error page," though, as stated in #22. However, I'm unable to reproduce, so I'm not going to be able to provide the error message.

Important note about Symfony releases: Symfony does not release minor version releases for all of its components at the same time, and there are a number of components that do not yet have a 6.4.9 release. Therefore, the Composer syntax I'm using is to specify the requirement is to require 6.4.9 or higher on ONLY the symfony/frameworkbundle component:

    "symfony/framework-bundle":"^6.4.9"

As a result, I get the latest stable release for all symfony components, some of which are still at 6.4.8, instead of getting development branches of components that do not have a 6.4.9 release, which would happen if I specified ^6.4.9 for all components listed in #2, above.

Because of this, I plan to postpone the update until all of the Symfony components have a 6.4.9 release.

I've also updated the available symfony submodules to 6.4.9 and initially things seemed to be work fine on Pantheon. But with some additional testing over a couple of days we're also running into an error related to caching as reported above. If a login attempt doesn't occur for awhile there is the following error:
The router "Symfony\Component\Routing\Router" cannot be warmed up because it does not implement "Symfony\Component\HttpKernel\CacheWarmer\WarmableInterface".

Refreshing the page and attempting again clears out the error and things work but only until some time passes again and another login is attempted.

Aknowledging mark_fullmer's message:

Reminder: the discussion in this issue does not involve code in the Drupal simplesamlphp_auth module. This is a discussion of a problem with Symfony and the SimpleSAMLphp library.

Don't let this backtrace full ya.

For those who need a text version of what callinmullaney posted in his image:
The debug information below may be of interest to the administrator / help desk:

SimpleSAML\Error\Error: UNHANDLEDEXCEPTION
Backtrace:
1 src/SimpleSAML/Error/ExceptionHandler.php:32 (SimpleSAML \Error\ExceptionHandler::customExceptionHandler)
[builtin] (N/A)
Caused by: LogicException: The router "Symfony\Component\Routing\Router" cannot be warmed up because it does not implement "Symfony\Component\HttpKernel\Cache

Backtrace:
6 /code/vendor/symfony/framework-bundle/CacheWarmer/RouterCacheWarmer.php:45 (Symfony\Bundle\FrameworkBundle\CacheWarmer \RouterCacheWarmer: :warmUp)
5 /code/vendor/symfony/http-kernel/CacheWarmer/CacheWarmer Aggregate.php:108 (Symfony\Component\HttpKernel\CacheWarmer\CacheWarmer Aggregate::warmUp)
4 /code/vendor/symfony/http-kernel/Kernel.php:552 (Symfony\Component\HttpKernel\Kernel::initializeContainer)
3 /code/vendor/symfony/http-kernel/Kernel.php:770 (Symfony\Component\HttpKernel\Kernel: :preBoot)
2 /code/vendor/symfony/http-kernel/Kernel.php:185 (Symfony\Component\HttpKernel\Kernel::handle)
1 src/SimpleSAML/Module.php:234 (SimpleSAML \Module: : process)
e public/module.php:17 (N/A)

Looks like 6.4.9 includes the fix for the ServiceNotFoundException: You have requested a non-existent service "serializer.normalizer.object". error:

See https://github.com/symfony/symfony/pull/57273, which is included in the 6.4.9 release notes: https://github.com/symfony/symfony/releases/tag/v6.4.9

But now we run into the new error:

LogicException: The router "Symfony\Component\Routing\Router" cannot be warmed up because it does not implement "Symfony\Component\HttpKernel\Cache"

Is this also a Symfony issue? Is there a ticket I can subscribe to?

Thanks!

I'm seeing these issue too. I've tried patching as mentioned in #3453721 💬 Fatal exception with simplesamlphp 2.2.2: non-existent service "serializer.normalizer.object" Closed: works as designed but the "WarmableInterface" cache issue persisted. I'm now testing rolling back to symfony/framework-bundle:6.4.3 and will report back.

Still seeing that cache error after rolling back to symfony/framework-bundle:6.4.3

The router "Symfony\Component\Routing\Router" cannot be warmed up because it does not implement "Symfony\Component\HttpKernel\CacheWarmer\WarmableInterface".

I've set up a temporary cron ping in an effort to bust the cache from the SimpleSAML welcome page to avoid concern from our users. Hopefully that will work for now until a fix is available.

Thanks

I've set up a temporary cron ping in an effort to bust the cache from the SimpleSAML welcome page

Can I ask what you did for the cron that's working as an interim bandaid, k_a_l? Also having this same WarmableInterface error, and based on my extremely superficial understanding, I'm assuming this is related to Symfony Issue #57599.

I've set up a temporary cron ping in an effort to bust the cache from the SimpleSAML welcome page

Can I ask what you did for the cron that's working as an interim bandaid, k_a_l? Also having this same WarmableInterface error, and based on my extremely superficial understanding, I'm assuming this is related to Symfony Issue #57599.

greysonniedbalski, because the error goes away on page refresh, it indicates a caching issue. To sidestep this, I've set up a cron job that requests the /simplesaml/module.php/core/welcome page in SimpleSAMLphp in an effort to “warm up” the Symfony router. This approach appears to be effective, as I haven't seen the error since implementing it.

We've found that the attached Symfony patch fixes the CacheWarmer regression introduced in 6.4.9.

It's a backport of: https://github.com/symfony/framework-bundle/commit/35d085dc18b494d20b757...

Thanks @jan.mashat. I've filed a bug so hopefully they will include the backport in a future 6.4.10 release:
https://github.com/symfony/symfony/issues/57727

I've had people here at work ask me "what are we patching". We are patching "symfony/framework-bundle" package with #31.

            "symfony/framework-bundle": {
                "#3452457: Fix Warming Up Route": "https://www.drupal.org/files/issues/2024-07-11/symfony_framework-bundle-fix_warming_up_routes-v6.4.9_backport-35d085d.patch"
            },

Thank you for the info, @k_a_l! I was able to get a cron working and it did the trick, but on the sites where I tested the symfony/framework-bundle patch in #31 💬 Update to Symfony 6.4.8 throws error Active we still saw the WarmableInterface error. I'll continue following the issue here and the one @roderickgadellaabsl filed.

Thank you all for all your work with this issue , I tested the patch (#31) over symfony/framework-bundle (version: v6.4.9) and I still having the "CacheWarmer" issue when I try to get logged in.

SimpleSAML\Error\Error: UNHANDLEDEXCEPTION
Backtrace:
1 src/SimpleSAML/Error/ExceptionHandler.php:32 (SimpleSAML\Error\ExceptionHandler::customExceptionHandler)
0 [builtin] (N/A)
Caused by: LogicException: The router "Symfony\Component\Routing\Router" cannot be warmed up because it does not implement "Symfony\Component\HttpKernel\CacheWarmer\WarmableInterface".
Backtrace:
6 /code/vendor/symfony/framework-bundle/CacheWarmer/RouterCacheWarmer.php:45 (Symfony\Bundle\FrameworkBundle\CacheWarmer\RouterCacheWarmer::warmUp)
5 /code/vendor/symfony/http-kernel/CacheWarmer/CacheWarmerAggregate.php:108 (Symfony\Component\HttpKernel\CacheWarmer\CacheWarmerAggregate::warmUp)
4 /code/vendor/symfony/http-kernel/Kernel.php:552 (Symfony\Component\HttpKernel\Kernel::initializeContainer)
3 /code/vendor/symfony/http-kernel/Kernel.php:770 (Symfony\Component\HttpKernel\Kernel::preBoot)
2 /code/vendor/symfony/http-kernel/Kernel.php:185 (Symfony\Component\HttpKernel\Kernel::handle)
1 src/SimpleSAML/Module.php:234 (SimpleSAML\Module::process)
0 public/module.php:17 (N/A

symfony/framework-bundle (along with symfony/cache) v6.4.10 was just released. Anyone know if this fixes the cachewarmer regression talked about above?

@jayemel, this latest update is working on one of my sites, still regression testing the update. Cautiously optimistic, though!

@jayemel - We just tested 6.4.10 on our Dev site, and SimpleSAML is working for us. It was not working with 6.4.8 or 6.4.9....we've been using the conflict block suggested by @berdir, which allowed us to push a few module security updates last week. Thanks for that suggestion @berdir.

We're going to do some more testing of 6.4.10 on our staging server, but we are cautiously optimistic as well.

Thank you all for this thread. Working through integrated composer with a custom upstream on Pantheon and ran into this issue. On symphony/6.4.10 the patch in 31 doesn't work as anticipated. I was experiencing this issue that went through a 6.4.9 iteration where the warming issue came up. I had to manually run cron and the issue appears to have cleared itself.

Again thank you all.