Doctrinebundle: [Autoloader] Dev mode warmups proxy classes for mappedSuperclass, prod does not

[blackandred]

Symfony version(s) affected: 4.1.2

Description
Hello, I'm developing an application with an inherited structure of modules -> components (DDD like).
I felt an inconsistency between dev and prod mode, the invalid code was working in dev but when running in prod was showing runtime errors (not on build stage).

How to reproduce
I suspect this situation (it is incorrect in my perspective):

Given we have a structure

Core/AbstractEntity // mappedSuperclass
SomeModule/Common/AbstractEntity  // mappedSuperclass
SomeModule/DragDrop/Entity // Entity
SomeModule/ElementCreation/Entity // Entity
SomeOtherModule/ElementCreation/Entity // Entity

1. SomeModule/Common/AbstractEntity/User has relation to SomeModule/Common/UserGroup - but it's a mistake, common/shared things should not have relations
2. I fetch DragDrop/User that extends CommonUser and do User->getGroup() // will return a PROXY CLASS FOR mappedSuperclass?

The problem is that in dev mode the proxy class for mappedSuperclass was generated... but it shouldn't or I'm wrong?

In prod mode the cache warmup was green, but the application were saying that failed to include() a non-existing file (it was trying to include a proxy class for mappedSuperclass

Fatal error: require(): Failed opening required '/builds/xxx/xxx/var/cache/prod/doctrine/orm/Proxies/__CG__AppDomainSomeModuleCommonComponentEntityClient.php' (include_path='/builds/xxx/xxx/vendor/pear/console_getopt:/builds/xxx/xxx/vendor/pear/db:/builds/xxx/xxx/vendor/pear/file:/builds/xxx/xxx/vendor/pear/pear-core-minimal/src:/builds/xxx/xxx/vendor/pear/pear_exception:.:/usr/local/lib/php') in /builds/xxx/xxx/vendor/doctrine/common/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php on line 212

Possible Solution
Make the dev validation better in this case?

[blackandred]

Moved from https://github.com/symfony/symfony/issues/28379

[blackandred]

Hi. Does somebody knows how to resolve the issue? Project team members at work are still doing mistakes in mapping and it makes the application unstable in prod mode.

[dmaicher]

@blackandred can you create a minimal example application that allows to reproduce this issue?

[alcaeus]

As @dmaicher said, a reproducer would be helpful here. At first, there shouldn't be an obvious difference between environments. Of course, having different values for the orm.auto_generate_proxy_classes configuration option causes subtle difference in behaviour:

With auto_generate_proxy_classes set to false, the ProxyCacheWarmer will generate proxy classes and the autoloader will skip it; this is reversed with auto_generate_proxy_classes set to true. However, there should never be a proxy for a mapped superclass, as the ProxyFactory in ORM skips any mapped superclass, embedded class or abstract class: https://github.com/doctrine/orm/blob/52d806a34a12b743a224bc70f506a991f0b36c7e/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L94.

So, I believe the error is not in whether mapped superclasses are generated or not, because ORM is pretty clear on that: they should not have proxies generated. However, something in your prod environment is trying to create a proxy for a mapped superclass, which doesn't exist. The autoloader then tries to generate the proxy before requiring the file. However, the autoloader never checks whether a file was actually generated. A sanity check there would be useful, but it wouldn't solve the problem at hand: it would simply throw an exception instead of letting the fatal error blow up.

I believe in this case, you should try to reproduce why ORM is trying to create a proxy for a mapped superclass, so this can be fixed in ORM: according to https://github.com/doctrine/orm/issues/3337, a proxy for a mapped superclass doesn't make sense, so the issue has to be somewhere in your code or your mapping.

I've created https://github.com/doctrine/common/issues/870 to tighten the error handling in the proxy autoloader, but I believe the issue is in ORM. I'm closing this here, but please report back here or in the https://github.com/doctrine/orm/issues once you have a reproducer that you'd like us to look at 👍

[blackandred]

Hi, thanks for engagement. Sorry, actually I do not have a use case to
reproduce the issue, it was reported long time ago.

On Thu, Apr 11, 2019 at 10:27 AM Andreas Braun [e-mail]
wrote:

As @dmaicher https://github.com/dmaicher said, a reproducer would be
helpful here. At first, there shouldn't be an obvious difference between
environments. Of course, having different values for the
orm.auto_generate_proxy_classes configuration option causes subtle
difference in behaviour:

With auto_generate_proxy_classes set to false, the ProxyCacheWarmer will
generate proxy classes and the autoloader will skip it; this is reversed
with auto_generate_proxy_classes set to true. However, there should
never be a proxy for a mapped superclass, as the ProxyFactory in ORM
skips any mapped superclass, embedded class or abstract class:
https://github.com/doctrine/orm/blob/52d806a34a12b743a224bc70f506a991f0b36c7e/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L94
.

So, I believe the error is not in whether mapped superclasses are
generated or not, because ORM is pretty clear on that: they should not have
proxies generated. However, something in your prod environment is trying to
create a proxy for a mapped superclass, which doesn't exist. The autoloader
then tries to generate the proxy before requiring the file. However, the
autoloader never checks whether a file was actually generated. A sanity
check there would be useful, but it wouldn't solve the problem at hand: it
would simply throw an exception instead of letting the fatal error blow up.

I believe in this case, you should try to reproduce why ORM is trying to
create a proxy for a mapped superclass, so this can be fixed in ORM:
according to doctrine/orm#3337
https://github.com/doctrine/orm/issues/3337, a proxy for a mapped
superclass doesn't make sense, so the issue has to be somewhere in your
code or your mapping.

I've created doctrine/common#870
https://github.com/doctrine/common/issues/870 to tighten the error
handling in the proxy autoloader, but I believe the issue is in ORM. I'm
closing this here, but please report back here or in the
https://github.com/doctrine/orm/issues once you have
a reproducer that you'd like us to look at 👍

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/doctrine/DoctrineBundle/issues/848#issuecomment-482019422,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVwEhq4YlX_xDx4K1oFjwmJxFNE19zxEks5vfvH3gaJpZM4Wtvl1
.

[toar86]

i also have this error, when switch symfony to prod mod, then proxies to mappedSuperclass wasn't generated and then i have error

[2020-09-28T08:40:41.771148+00:00] php.WARNING: Warning: require(/home/xxx/public_html/var/cache/prod/doctrine/orm/Proxies/__CG__AppEntityCoreEntity.php): failed to open stream: No such file or directory {"exception":"[object] (ErrorException(code: 0): Warning: require(/home/xxx/public_html/var/cache/prod/doctrine/orm/Proxies/__CG__AppEntityCoreEntity.php): failed to open stream: No such file or directory at /home/xxx/public_html/vendor/doctrine/common/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php:204)"} [] [2020-09-28T08:40:41.771594+00:00] php.CRITICAL: Fatal Compile Error: require(): Failed opening required '/home/xxx/public_html/var/cache/prod/doctrine/orm/Proxies/__CG__AppEntityCoreEntity.php' (include_path='.:/opt/cpanel/ea-php72/root/usr/share/pear') {"exception":"[object] (Symfony\\Component\\ErrorHandler\\Error\\FatalError(code: 0): Compile Error: require(): Failed opening required '/home/xxx/public_html/var/cache/prod/doctrine/orm/Proxies/__CG__AppEntityCoreEntity.php' (include_path='.:/opt/cpanel/ea-php72/root/usr/share/pear') at /home/xxx/public_html/vendor/doctrine/common/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php:204)"} [] [2020-09-28T08:40:41.776896+00:00] request.CRITICAL: Uncaught PHP Exception Symfony\Component\ErrorHandler\Error\FatalError: "Compile Error: require(): Failed opening required '/home/xxx/public_html/var/cache/prod/doctrine/orm/Proxies/__CG__AppEntityCoreEntity.php' (include_path='.:/opt/cpanel/ea-php72/root/usr/share/pear')" at /home/xxx/public_html/vendor/doctrine/common/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php line 204 {"exception":"[object] (Symfony\\Component\\ErrorHandler\\Error\\FatalError(code: 0): Compile Error: require(): Failed opening required '/home/xxx/public_html/var/cache/prod/doctrine/orm/Proxies/__CG__AppEntityCoreEntity.php' (include_path='.:/opt/cpanel/ea-php72/root/usr/share/pear') at /home/xxx/public_html/vendor/doctrine/common/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php:204)"} []

[stof]

@toar86 see the explanation above. You would need to investigate the stack trace to find out why such a proxy for a mapped superclass was requested at all.
Not generating proxies for mapped superclasses is the intended behavior as such proxies don't make sense.