Serialization of 'Closure' is not allowed when using @runInSeparateProcess

[enumag]

Q	A
PHPUnit version	9.2.5
PHP version	7.4.7
Installation Method	Composer

Summary

One of our tests started failing with Serialization of 'Closure' is not allowed. When I removed the @runInSeparateProcess (which I have to keep as workaround for https://bugs.php.net/bug.php?id=79646) I got an entirely different error which helped me find the problem in the test.

Apparently there is some issue with process isolation - the data that are serialized to be sent back to the original process contain a Closure and the serialization fails as a result.

Note: This has nothing to do with #2739 - that's about sending data into the test, this is about getting data back.

I'm not sure what data are serialized and where the serialization happens so I'm unable to provide more details and a reproducer for now. Can you point me where in PHPUnit's source code this serialization happens? (Using -v and --debug didn't get me a stack trace.)

[sebastianbergmann]

Thank you for your report.

Please provide a minimal, self-contained, reproducing test case that shows the problem you are reporting.

Without such a minimal, self-contained, reproducing test case I will not be able to investigate this issue.

[enumag]

@sebastianbergmann Please read the last paragraph:

I'm not sure what data are serialized and where the serialization happens so I'm unable to provide more details and a reproducer for now. Can you point me where in PHPUnit's source code this serialization happens? (Using -v and --debug didn't get me a stack trace.)

[enumag]

I need to check the data that are being serialized in order to provide a reproducer. Without knowing where the serialization happens I'm unable to do so.

[mirko-pagliai]

I have the same problem. And I also don't understand what causes it, what data are serialized and where the serialization happens.

[ramsey]

This appears to happen when an assertion called within a Closure fails.

Here's an example that reproduces this:

/**
 * @runInSeparateProcess
 * @preserveGlobalState disabled
 */
public function testSomething(): void
{
    $mock = $this->createMock(\DateTime::class);
    $mock->expects($this->once())
        ->method('format')
        ->with($this->callback(function ($arg1): bool {
            $this->assertSame('foo', $arg1);

            return true;
        }));

    $mock->format('bar');
}

When run as-is, this produces the following fatal error:

PHP Fatal error:  Uncaught Exception: Serialization of 'Closure' is not allowed in Standard input code:89
Stack trace:
#0 Standard input code(89): serialize(Array)
#1 Standard input code(122): __phpunit_run_isolated_test()
#2 {main}
  thrown in Standard input code on line 89
Fatal error: Uncaught Exception: Serialization of 'Closure' is not allowed in Standard input code:89
Stack trace:
#0 Standard input code(89): serialize(Array)
#1 Standard input code(122): __phpunit_run_isolated_test()
#2 {main}
  thrown in Standard input code on line 89

If you change the the argument value for $mock->format() to 'foo', then it passes normally. If you leave it as 'bar' but remove the annotations, you see:

Expectation failed for method name is "format" when invoked 1 time(s)
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'foo'
+'bar'

[Zrnik]

Hello,

i can confirm it has something to do with

This appears to happen when an assertion called within a Closure fails.

I would extend it to 'when assertion is called outside of the test function.

For example:

<?php declare(strict_types=1);

class ExampleTest extends TestCase
{
    /**
     * @runInSeparateProcess
     */
    public function testLanguage(): void
    {
        $languageSwitch = Something::something();

        $this->switchLocale($languageSwitch, "en");

        // ... test something with english ...

        $this->switchLocale($languageSwitch, "de");

        // ... test something with german ...

    }

    private function switchLocale($languageSwitch, $language)
    {
        $languageSwitch->setLanguage($language);

        // This next assert is throwing the error
        // if you comment it, it works fine

        // Edit: only if the assertion fails.

        $this->assertSame(
            $language,
            $languageSwitch->getLanguage()
        );

    }
}

[sebastianbergmann]

Do not call assertions in closures then, sorry.

[Kingdutch]

This has been occasionally plaguing me for a few months now so I spent a few hours to dig deeper.

Do not call assertions in closures then, sorry.

While I understand the sentiment, that scope for the bug is a bit too small, as illustrated by Zrniks's example and my own tests.

In my investigation I was able to see a difference between self::assertEquals([], $expected); and self::assertEmpty($expected). The former did cause the issue, the latter did not. (Using assertEmpty is not always a workaround in case a comparison needs to be made with a non-empty array, this was just my specific investigation case.)

I was able to figure out that the closure serialisation occurred in the comparisonFailure argument to the ExpectationFailedException instance that's been created on line 109 in the IsEqual comparator. Removing the second parameter fixes the issue but obviously removes a lot of valuable debug information.

By modifying TestCaseMethod.tpl.dist I was able to narrow it down further to the following part of the TestResult: $result->failures()[0]->thrownException().

That is an exception from the test case. Looking further I found that it's backtrace contained a reference to a different error handler that contained itself an error with a stacktrace of a function stack call that contained a closure.

So the error occurs "when any part of your application that produces an error contains a function in the stacktrace that has a closure as one of its arguments".

In my specific case the serialization error was caused in an error with a callstack that contained a call to Visitor::visit that takes a closure.

Although not directly useful, to illustrate the difficulty of debugging this, the full path from TestResult to offending array entry was as follows: $result->failures()[0]->thrownException()[4]['args'][0]->errors[0]->getTrace()[3]['args'][1] where $result is a TestResult instance in __phpunit_run_isolated_test.