Psr\Log\AbstractLogger Fatal Error

[lmjhs]

Describe your environment
PHP 8.3.19
Composer 2.8.8

Steps to reproduce
When upgrading to the latest version of the SDK (1.5.0 - 1.6.0) a PHP fatal error is being generated when the SDK is autoloaded.

What is the expected behavior?
No errors

What is the actual behavior?
PHP Fatal error: Declaration of Psr\Log\AbstractLogger::emergency(Stringable|string $message, array $context = []): void must be compatible with Psr\Log\LoggerInterface::emergency($message, array $context = []) in /srv/vendor/psr/log/src/LoggerTrait.php on line 18

Additional context
The issue appears to originate from line 190 in SdkAutoloader.php

private static function loadConfigPropertiesFromEnv(): ConfigProperties
{
    ...
    $context = new \OpenTelemetry\API\Configuration\Context();
}

[brettmc]

Ooh. We've had a couple of reports like this in the last couple of weeks. eg #1661
It sounds like corruption in your vendor dir, since the complaint is that psr/log is not compatible with another class in psr/log ?

[lmjhs]

Hi @brettmc, thanks for the link to the other issue, that is exactly the same issue as this one.

it is a very strange error and took me a while to figure out it was actually the open-telemetry packages that are part of the problem. I've seen this problem in 3 of our projects so not isolated however they are all Laravel based.

They run in a docker container so can be reasonably confident it's not a caching issue as we can build them from scratch.

It's possible it's a combination of packages that is the issue, I will try to isolate the issue to a simple example.

[lmjhs]

Hi @brettmc, I have created a repo with a cut down example of the problem

https://github.com/lmjhs/otel-bug-example

It only includes the following packages and pulls the latest official PHP 8.3 Docker image

• "psr/log": "^3.0"
• "open-telemetry/api": "^1.0"
• "open-telemetry/sdk": "^1.0"

The important part is that the OTEL_PHP_AUTOLOAD_ENABLED env var must be set to true and it appears the issue may only exist when ran from the composer script, I can't seem to replicate when running the script directly.

Link to the failed action
https://github.com/lmjhs/otel-bug-example/actions/runs/16596761090/job/46945215263#step:6:47

[lmjhs]

I think I have found the problem, this issue raised with composer is very similar and basically explains that when running scripts from composer the Psr/Log package is locked to the version shipped in the composer.phar
composer/composer#11437

The recommendation is that any code that runs as a script needs to comply with that restriction.

[brettmc]

The important part is that the OTEL_PHP_AUTOLOAD_ENABLED env var must be set to true and it appears the issue may only exist when ran from the composer script

That's interesting... You mean something like this?

"scripts": {
    "start-app": "php -S localhost:8000 -t public"
  }

Do seldeak's comments help at all? Since it also happens during postAutoloadDump (from another bug report), maybe we need to drop support for psr/log:3 for the time being?

[lmjhs]

Sorry no the issue is a combination of Composer, Laravel and OpenTelemetry.

The issue starts with the fact that there is a script using a class which is in the Laravel application template

https://github.com/laravel/laravel/blob/12.x/composer.json#L36

"scripts": {
        "post-autoload-dump": [
            "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",

When Composer runs a script as a class it simply runs it within the Composer runtime which mean you are inheriting the dependencies of Composer which is where the old version of Psr/Log comes from.

That script then runs the Composer autoload.php to load the dependencies so it can run functionality in Laravel however that also means any code that runs as part of the autoload.php also inherits the Composer builit in dependencies.

https://github.com/laravel/framework/blob/12.x/src/Illuminate/Foundation/ComposerScripts.php#L41

public static function postAutoloadDump(Event $event)
{
    require_once $event->getComposer()->getConfig()->get('vendor-dir').'/autoload.php';

    static::clearCompiled();
}

The reason it affects OpenTelemetry is because as part of the autoload it requires the SDK _autoload.php file

https://github.com/open-telemetry/opentelemetry-php/blob/main/composer.json#L79

"files": [
    ...
    "src/SDK/_autoload.php"
]

Which in turn instantiates a Psr/Log/NullLogger which is incompatible with the Composer built in dependency.

So it sounds like this is as designed by Composer so I think the actual solution is to change the Laravel postAutoloadDump script to use a PHP command instead which will start a new process and not have the overlap with dependencies.

So I don't think this is particularly an OpenTelemetry issue but can potentially trip people up if they are trying to implement OTel with Laravel.

[lmjhs]

I've raised this as an issue with the Laravel template, let's see what they say!

[trigrab]

I had the same problem with the symfony flex command composer dump-env.

I finally solved it with this in my composer.json:

{
...
    "scripts": {
        "pre-command-run": [
            "@putenv OTEL_PHP_AUTOLOAD_ENABLED=false"
        ],
...
}

As far as I understood from composer/composer#11437 (comment) this is always needed if we run a composer command and have OTEL_PHP_AUTOLOAD_ENABLED=true in our environment because composer uses an older version of psr/log then the opentelemetry sdk.
Is that correct?

[lmjhs]

Thanks @trigrab, yeah that will do the trick. The change I suggested for Laravel got reverted as it needs to run immediately after the autoload in composer. Disabling OTEL for composer commands makes sense and solves for me to.