New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PHP8.1: Monolog\Handler\NullHandler::$level must not be accessed before initialization (git_commit_message) #1020
Comments
Hi guys, this issue may be solved? IDK if comes from gitlab or monolog library but for new projects (at least symfony projects) is a problem because it comes out of box with Monolog v3 :( |
Sorry, don't have a lot of free time to spend on this atm. Did a quick test and it looks like it is an amphp/parallel (serialization) issue.
The issue is caused by the Why it is not able to deserialize the logger is a bit of a mistery to me at this point. Since the level is configured at constructor level and added to a property, it should just deserialize into that. |
@veewee thank you for your help, I will try some workarounds to fix this, if I catch a good solution I will post it here Thx |
I put some additional effort in this, but sadly no solution yet. I added a dump before and after serialization in Before, the task has a log level:
Next it is able to detect the enum and add it to the scope. Yet after deserializing the task, the log level is uninitialized: (that's what is giving you the error)
I tried reproducing a simple test case for this issue so that it can be dealt with in the serializable package, but I haven't found a way to reproduce it inside the pest testsuite of that package. Even tried by injecting a custom symfony container to rule that dependency out as well without any luck. So it looks like that package is behaving correctly. Of course I did not stop there ... Next step was to rule out amp/parallel-functions. $enqueueParallelTask = function () use ($task, $runnerContext, $next, $currentEnv): Promise {
$run = new SerializableClosure(function () use($task, $runnerContext, $next, $currentEnv) {
var_dump($task);
$_ENV = array_merge($currentEnv, $_ENV);
/** @var TaskResultInterface $result */
$result = wait($next($task, $runnerContext));
return $result;
});
$serialized = serialize($run);
//echo $serialized;
$deserialized = unserialize($serialized, ['allowed_classes' => true]); // also tried adding ->getClosure()
return coroutine($deserialized)();
}; This results in the same failure:
When I do inspect the serialized version, I can see that there is no level available in the NullHandler,
So at this point I am pretty sure that the issue is somewhere inside laravel/serializable-closure or maybe even in PHP's serialize/unserialize function, yet I am not able to reproduce a simple test case in order to fix the bug. Not sure on how to get forward with this issue at this moment. |
@veewee nice catch 😎 maybe should be a problem on __sleep() method in the serialized object ? |
It might indeed be related to the sleep method in monologs base-handler. |
Hey, so I had a look and indeed it seems to be caused by the __sleep override done in Seldaek/monolog@af7c0a7 (2.0.0) to fix Seldaek/monolog#365. The problem is get_object_vars only sees protected/public properties and not the private properties from the child classes. I'll fix that on the Monolog end. |
I'd be happy if someone can confirm using the latest monolog 2.x-dev or 3.x-dev if this is fixed for you. |
Well Monolog 2.8.0/3.2.0 are out with the fix so hopefully it helps :) |
Thank you @Seldaek , I can confirm this fixes the issue :) |
Nice, thanks! Reopened: Maybe best to reflect this bug in our dependencies as well, so this package can't be installed with the known bug. |
1.13.0
I get the error
Monolog\Handler\NullHandler::$level must not be accessed before initialization
when I try to use thegit_commit_message
check. Other checks pass.My configuration
(PHP 8.1)
Steps to reproduce:
Result:
With GrumPHP 1.12.0 (and therefore Monolog 2 instead of 3) the check works (see #1014).
The text was updated successfully, but these errors were encountered: