Type error results in zero exit code starting with PHP 8.3.0

[greg0ire]

Symfony version(s) affected

7.0.3

Description

When a type error occurs in a Symfony app that is run with the CLI SAPI, the exit code is zero.

How to reproduce

• paste this in a Symfony command, at the beginning of the execute method, it should result in a type error: (function (int $toto): void { echo $toto; })('toto');
• run that command
• run echo $? to get the exit code

You should see the type error, and you will also see that it exits with zero, when I would expect it to exit with anything else, just like for exceptions.

Possible Solution

Deprecate not calling setCatchErrors() in the next minor
Change this default value and remove the deprecation in the next major version:

symfony/src/Symfony/Component/Console/Application.php

Line 80 in fd53091

private bool $catchErrors = false;

Additional Context

I cannot reproduce that issue with throw new \Exception, so maybe it only affects errors.
A workaround is to add $application->setCatchErrors(true);.

How did it work before? I believe that before #50420 type error also didn't result in non-zero code. If so then your issue is more like a feature rather than bug.

[greg0ire]

I believe that before #50420 type error also didn't result in non-zero code.

That sounds a lot like a bug, and I think the root cause is this line:

symfony/src/Symfony/Component/Console/Application.php

Line 178 in fd53091

$exitCode = $e->getCode();

It was introduced right from the beginning: 6feaecf#diff-604e88acd1f392ef7bd3ba584f8ddf736bee74777ed59cce245e387a36183fb1R119

I wonder what the rationale behind doing this is, I mean, the default value is 0: https://3v4l.org/cUGg9

On my machine, PHP exits with a 255 exit code when I throw an exception, so if anything, it feels like Symfony silences the error 😬

These lines are supposed to set it back to 1:

symfony/src/Symfony/Component/Console/Application.php

Lines 181 to 183 in fd53091

	if ($exitCode <= 0) {
	$exitCode = 1;
	}

[greg0ire]

New suspect that agrees with @derrabus ' tagging: the error handler component. Here is a reproducer:

<?php

use Symfony\Component\ErrorHandler\ErrorHandler;

require_once 'vendor/autoload.php';

ErrorHandler::register();

(function (int $toto): void { echo $toto; })('toto');

[llupa]

This problem just caused a lot of confusion for some post deployment commands we have in our K8s cluster. A prod image made it into a dev env (due to tagging name collision) and all commands complained that require-dev classes were not found, but the exit code was 0 anyway and the pod went live.

Adding the following, if others encounter this too, from a slack thread, thanks to @wouterj, will help:

// in your bin/console change:

return new Application($kernel);

// to

$app = new Application($kernel);
$app->setCatchErrors(true);

return $app;

[greg0ire]

My reproducer above does not seem to always work. I think depending on the php configuration, but I'm really not sure. I discarded the environment because the error handler does not seem to pull much from the env, at least not through getenv. When the issue happen, using var_dump(set_exception_handler('is_int'));die(); as the first line of ErrorHandler::handleException() produces… null. So that method is called, but there is no exception handler?

[greg0ire]

Ah, this seems to be PHP-8.3-specific 💡

• https://3v4l.org/KfilR#v8.3.3
• https://3v4l.org/KfilR#v8.2.16

Reported the regression at php/php-src#13446

[greg0ire]

The logic for accessing the exception handler within ErrorHandler::handleFatalError was added in #25408

Before that, fatal errors were handled with the error handler rather than the exception handler.