orm: Upgrading from 2.16.3 to 2.17.0 breaks serialization when using symfony/var-exporter

https://github.com/doctrine/orm/releases/tag/2.17.1 released

Fix for Symfony: https://github.com/symfony/symfony/pull/52618

Thank you all for the help on this one!

@greg0ire https://github.com/doctrine/orm/pull/11065

Hi. I have the same error. Reverting to 2.16.3 solves the problem.

Awesome, many thanks to everyone who got involved so quickly to resolve this 🥳 !

@szczyglis-dev I said: YOU JUST NEED TO WAIT

So just wait. No need for more reports.

On 2.16.3 it yields this file:

<?php //ec5dca27522cfad6c17af2027e1d3000

return [PHP_INT_MAX, static function () { return \Symfony\Component\VarExporter\Internal\Hydrator::hydrate(
    $o = [
        clone (($p = &\Symfony\Component\VarExporter\Internal\Registry::$prototypes)['Doctrine\\ORM\\Query\\ParserResult'] ?? \Symfony\Component\VarExporter\Internal\Registry::p('Doctrine\\ORM\\Query\\ParserResult')),
        clone ($p['Doctrine\\ORM\\Query\\Exec\\SingleSelectExecutor'] ?? \Symfony\Component\VarExporter\Internal\Registry::p('Doctrine\\ORM\\Query\\Exec\\SingleSelectExecutor')),
        clone ($p['Doctrine\\ORM\\Query\\ResultSetMapping'] ?? \Symfony\Component\VarExporter\Internal\Registry::p('Doctrine\\ORM\\Query\\ResultSetMapping')),
    ],
    null,
    [
        'Doctrine\\ORM\\Query\\Exec\\AbstractSqlExecutor' => [
            '_sqlStatements' => [
                1 => 'SELECT c0_.id AS id_0, c0_.name AS name_1, c0_.slug AS slug_2, c0_.icon AS icon_3, c0_.datatricsId AS datatricsId_4, c0_.weight AS weight_5, c0_.filteringEnabled AS filteringEnabled_6, c0_.root AS root_7, c0_.lvl AS lvl_8, c0_.lft AS lft_9, c0_.rgt AS rgt_10, c0_.createdAt AS createdAt_11, c0_.updatedAt AS updatedAt_12, c0_.parent_id AS parent_id_13, c0_.seoDetails_id AS seoDetails_id_14 FROM category c0_ WHERE c0_.lft <= 1 AND c0_.rgt >= 2 AND c0_.root = ? ORDER BY c0_.lft ASC',
            ],
        ],
        'stdClass' => [
            'aliasMap' => [
                2 => [
                    'node' => '<redacted>\\Entity\\Category',
                ],
            ],
            'fieldMappings' => [
                2 => [
                    'id_0' => 'id',
                    'name_1' => 'name',
                    'slug_2' => 'slug',
                    'icon_3' => 'icon',
                    'datatricsId_4' => 'datatricsId',
                    'weight_5' => 'weight',
                    'filteringEnabled_6' => 'filteringEnabled',
                    'root_7' => 'root',
                    'lvl_8' => 'level',
                    'lft_9' => 'left',
                    'rgt_10' => 'right',
                    'createdAt_11' => 'createdAt',
                    'updatedAt_12' => 'updatedAt',
                ],
            ],
            'typeMappings' => [
                2 => [
                    'parent_id_13' => 'smallint',
                    'seoDetails_id_14' => 'integer',
                ],
            ],
            'entityMappings' => [
                2 => [
                    'node' => null,
                ],
            ],
            'metaMappings' => [
                2 => [
                    'parent_id_13' => 'parent_id',
                    'seoDetails_id_14' => 'seoDetails_id',
                ],
            ],
            'columnOwnerMap' => [
                2 => [
                    'id_0' => 'node',
                    'name_1' => 'node',
                    'slug_2' => 'node',
                    'icon_3' => 'node',
                    'datatricsId_4' => 'node',
                    'weight_5' => 'node',
                    'filteringEnabled_6' => 'node',
                    'root_7' => 'node',
                    'lvl_8' => 'node',
                    'lft_9' => 'node',
                    'rgt_10' => 'node',
                    'createdAt_11' => 'node',
                    'updatedAt_12' => 'node',
                    'parent_id_13' => 'node',
                    'seoDetails_id_14' => 'node',
                ],
            ],
            'declaringClasses' => [
                2 => [
                    'id_0' => '<redacted>\\Entity\\Category',
                    'name_1' => '<redacted>\\Entity\\Category',
                    'slug_2' => '<redacted>\\Entity\\Category',
                    'icon_3' => '<redacted>\\Entity\\Category',
                    'datatricsId_4' => '<redacted>\\Entity\\Category',
                    'weight_5' => '<redacted>\\Entity\\Category',
                    'filteringEnabled_6' => '<redacted>\\Entity\\Category',
                    'root_7' => '<redacted>\\Entity\\Category',
                    'lvl_8' => '<redacted>\\Entity\\Category',
                    'lft_9' => '<redacted>\\Entity\\Category',
                    'rgt_10' => '<redacted>\\Entity\\Category',
                    'createdAt_11' => '<redacted>\\Entity\\Category',
                    'updatedAt_12' => '<redacted>\\Entity\\Category',
                ],
            ],
        ],
    ],
    $o[0],
    [
        [
            "\0".'Doctrine\\ORM\\Query\\ParserResult'."\0".'sqlExecutor' => $o[1],
            "\0".'Doctrine\\ORM\\Query\\ParserResult'."\0".'resultSetMapping' => $o[2],
            "\0".'Doctrine\\ORM\\Query\\ParserResult'."\0".'parameterMappings' => [
                'rid' => [
                    0,
                ],
            ],
        ],
    ]
); }];

Thanks, but we have 2 fixes on the way already, and pinpointed the issue a few messages ago. You just need to wait for either a new version of doctrine/orm or symfony/var-exporter.

One could argue that this method should not return the properties with their internal visibility names, but as @greg0ire mentioned before, get_object_vars is not an option in this case as this will skip the private properties of subclasses. Using Reflection is another option, but I’m not sure if that’s the best option in this case neither 😕

@nicolas-grekas in short, this is the problem:

<?php

use Symfony\Component\VarExporter\VarExporter;

require_once '/path/to/project-with-var-exporter/autoload.php';

class T {
  protected $a;

  public function __construct()
  {
    $this->a = '123';
  }

  public function __sleep(): array
  {
    //return ['a'];
    return array_keys((array) $this);
  }
}

var_dump(VarExporter::export(new T()));
var_dump(serialize(new T()));

The (array) $this returns the properties with the internal visibility names, which does not work with VarExporter.

Returning those properties with the internal visibility names and executing serialize on it will work however.

From what I can tell though, it breaks on production when storing and retrieving the ParserResult instance. So production works on first deploy (no cache). Then as soon as cache items get generated, things break.

The PhpFilesAdapter uses VarExporter.

The result of VarExporter::export in PhpFilesAdapter with my change:

string(2103) "\Symfony\Component\VarExporter\Internal\Hydrator::hydrate(
    $o = [
        clone (($p = &\Symfony\Component\VarExporter\Internal\Registry::$prototypes)['Doctrine\\ORM\\Query\\ParserResult'] ?? \Symfony\Component\VarExporter\Internal\Registry::p('Doctrine\\ORM\\Query\\ParserResult')),
        clone ($p['Doctrine\\ORM\\Query\\Exec\\SingleSelectExecutor'] ?? \Symfony\Component\VarExporter\Internal\Registry::p('Doctrine\\ORM\\Query\\Exec\\SingleSelectExecutor')),
        clone ($p['Doctrine\\ORM\\Query\\ResultSetMapping'] ?? \Symfony\Component\VarExporter\Internal\Registry::p('Doctrine\\ORM\\Query\\ResultSetMapping')),
    ],
    null,
    [
        'Doctrine\\ORM\\Query\\Exec\\AbstractSqlExecutor' => [
            'sqlStatements' => [
                1 => 'Ive removed info here',
            ],
        ],
        'stdClass' => [
            'scalarMappings' => [2 => ['I removed info here']],
            'typeMappings' => [
                2 => ['Ive removed info here'],
            ],
        ],
    ],
    $o[0],
    [
        [
            "\0".'Doctrine\\ORM\\Query\\ParserResult'."\0".'sqlExecutor' => $o[1],
            "\0".'Doctrine\\ORM\\Query\\ParserResult'."\0".'resultSetMapping' => $o[2],
            "\0".'Doctrine\\ORM\\Query\\ParserResult'."\0".'parameterMappings' => [
                'asdf' => [
                    0,
                ],
            ],
        ],
        1,
    ]
)"

Result of unmodified code:

string(1560) "\Symfony\Component\VarExporter\Internal\Hydrator::hydrate(
    $o = [
        clone (($p = &\Symfony\Component\VarExporter\Internal\Registry::$prototypes)['Doctrine\\ORM\\Query\\ParserResult'] ?? \Symfony\Component\VarExporter\Internal\Registry::p('Doctrine\\ORM\\Query\\ParserResult')),
        clone ($p['Doctrine\\ORM\\Query\\Exec\\SingleSelectExecutor'] ?? \Symfony\Component\VarExporter\Internal\Registry::p('Doctrine\\ORM\\Query\\Exec\\SingleSelectExecutor')),
        clone ($p['Doctrine\\ORM\\Query\\ResultSetMapping'] ?? \Symfony\Component\VarExporter\Internal\Registry::p('Doctrine\\ORM\\Query\\ResultSetMapping')),
    ],
    null,
    [
        'stdClass' => [
            'scalarMappings' => [
                2 => ['ive removed info here'],
            ],
            'typeMappings' => [
                2 => ['ive removed info here'],
            ],
        ],
    ],
    $o[0],
    [
        [
            "\0".'Doctrine\\ORM\\Query\\ParserResult'."\0".'sqlExecutor' => $o[1],
            "\0".'Doctrine\\ORM\\Query\\ParserResult'."\0".'resultSetMapping' => $o[2],
            "\0".'Doctrine\\ORM\\Query\\ParserResult'."\0".'parameterMappings' => [
                'asdfasdf' => [
                    0,
                ],
            ],
        ],
        1,
    ]
)"

Notice the missing sqlStatements key.

You can check this by dumping the result of VarExporter::export in PhpFilesAdapter on line 227

@greg0ire Yes, I’m aware of the fact that it governs what to serialize. I’m switching to get_object_vars to get rid of the \0x\0 prefixes, which I thought was causing the issue.

As you can see in the grep result, my modification will still ensure sqlStatements is serialized, not _sqlStatements.

Anyways, i’m not saying this is the fix, but this is what I see

I take it back, development release works (but runs in development mode). Production broken again. Manually purging caches did not resolve it there. Diving back into what the cause is.

For me it was resolved by purging our cache more explicitly.