Clearing the em before accessing an uninitialized relation results in "typed property must not be accessed before initialization..." error

[kbond]

BC Break Report

Q	A
BC Break	yes
Version	2.14.0

Summary

Consider the following code:

$results = $repo->createQueryBuilder('e')
    ->innerJoin('e.relation', 'r')
    ->getQuery()
    ->execute()
;

$em->clear();

echo $results[0]->relation->value;

Previous behavior

In 2.13.5, would echo the relation's value property.

Current behavior

In 2.14.0:

Error: Typed property Relation::$value must not be accessed before initialization

@nicolas-grekas, could this be related to #10187?

Reproducer: #10337

[darthf1]

I have the same exception, but thrown in my tests when a method is called on a proxied object. The proxied object is returned via the referenceRepository of LiipTestFixturesBundle

1) Tests\Functional\UserInterface\DataCube\Rest\DataCubeProjectionTest::testGetDataCubes
Error: Typed property Domain\DataCube\DataCube::$analysisType must not be accessed before initialization
/builds/xxx/api/src/Domain/DataCube/DataCube.php:101
/builds/xxx/api/var/cache/test/doctrine/orm/Proxies/__CG__DomainDataCubeDataCube.php:210
/builds/xxx/tests/Functional/UserInterface/DataCube/Rest/DataCubeProjectionTest.php:59

[brilsergei]

I have probably similar problem in tests using the referenceRepository of LiipTestFixturesBundle. I call method which should return a string (field of an entity) but it returns null. While debugging found that in older version of this lib in method \Doctrine\ORM\UnitOfWork::createEntity the condition if (isset($this->identityMap[$class->rootEntityName][$idHash])) { gets true while in 2.14 this condition gets false. identityMap is empty in UnitOfWork object.

[mathieudz]

Same problem here since 2.14: createEntity ignores the existing proxy object (specified in the hint) and returns a new one instead. As result, the proxy object stays uninitialized. Results eventually in same error message as the title of this issue.

[nicolas-grekas]

Thanks for the reproducer. I will definitely have a look, just not before the 9th.

[simonberger]

The bug is caused by the removal of those three lines.
https://github.com/doctrine/orm/pull/10187/files#diff-c9c1faa5750ed5a13ec97a922d181d5b26a9f74fd79345cef5264725054cef2bL151-L153

After adding them again the test succeeds and none fails (in PHP 7.4 environment).
Yet there might be a good reason to do this change. My understanding is not good enough. The removed lines are looking rather isolated tho and all other usages of the constant are still in place.

[jetrodn]

The bug is caused by the removal of those three lines. https://github.com/doctrine/orm/pull/10187/files#diff-c9c1faa5750ed5a13ec97a922d181d5b26a9f74fd79345cef5264725054cef2bL151-L153

After adding them again the test succeeds and none fails (in PHP 7.4 environment). Yet there might be a good reason to do this change. My understanding is not good enough. The removed lines are looking rather isolated tho and all other usages of the constant are still in place.

I have faced with the same issue and can confirm that reverting those lines fixed the issue in my case.