Symfony version(s) affected

5.4

Description

I recently stumbled upon an issue on the CI of one of our projects relying on a Symfony CLI server running in test env without debug mode enabled:

one of the third party libraries triggers some PHP 8 deprecations,
which are output to the response of the 1st call made to the running application and making the test fail.

How to reproduce

A simple reproducer is available here: https://github.com/ogizanagi/sf-deprec-issue-reproducer

Use:

rm -rf var/cache
APP_DEBUG=0 symfony serve

and go to localhost:8000 to observe the deprecation output to the response:

Possible Solution

The following patch to the GenericRuntime:

diff --git a/src/Symfony/Component/Runtime/GenericRuntime.php b/src/Symfony/Component/Runtime/GenericRuntime.php
index 1d77529dfa..bb7455641d 100644
--- a/src/Symfony/Component/Runtime/GenericRuntime.php
+++ b/src/Symfony/Component/Runtime/GenericRuntime.php
@@ -71,15 +71,15 @@ class GenericRuntime implements RuntimeInterface
         if ($debug) {
             umask(0000);
             $_SERVER[$debugKey] = $_ENV[$debugKey] = '1';
-
-            if (false !== $errorHandler = ($options['error_handler'] ?? BasicErrorHandler::class)) {
-                $errorHandler::register($debug);
-                $options['error_handler'] = false;
-            }
         } else {
             $_SERVER[$debugKey] = $_ENV[$debugKey] = '0';
         }
 
+        if (false !== $errorHandler = ($options['error_handler'] ?? BasicErrorHandler::class)) {
+            $errorHandler::register(false);
+            $options['error_handler'] = false;
+        }
+
         $this->options = $options;
     }

aims to register the error handler, regardless of the $debug flag (but still passing it to the error handler which will account for it)

which solves the issues and the deprecation is properly absent from the response & logged:

[Application] Jun 16 08:23:06 |INFO   | DEPREC Deprecated: Return type of App\Foo::jsonSerialize() should either be compatible with JsonSerializable::jsonSerialize(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice

But I'm unaware if this solution could be wrong or not, since not registering at all an error handler in non-debug mode was clearly intended from the code.

The issue is mitigated as well on production servers for which display_errors should be disabled.

Additional Context

No response