[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 symfony/symfony#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 doctrine/orm#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 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](ORM issue tracker) 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 ***@***.***> 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 <doctrine/orm#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 <doctrine/common#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](ORM issue tracker) 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 <#848 (comment)>, 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.