mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
enable_lazy_ghost_objects: true prevents detection of proxy creation errors at Symfony compile time
#7352
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @chrif on GitHub (Mar 22, 2024).
enable_lazy_ghost_objects: falseis deprecated, but when it istrue, clearing the Symfony cache is not enough to get theUnable to create a proxy for a readonly classerror. It is only when the proxy class is used that we get it.So in dev we have
auto_generate_proxy_classes: trueand we didn't get an error when developing. I guess the problematic proxy was not used in the development use case.In production we have
auto_generate_proxy_classes: falseas recommended. We also have a functional test to check that the prod Symfony cache can be cleared. It passed the test.It's only when we released and used the proxy class that we got the
Unable to create a proxy for a readonly class.With
enable_lazy_ghost_objects: falseeverything works fine, but we have a deprecation message.@stof commented on GitHub (Mar 22, 2024):
Can you share the stack trace of the exception you got to see when it was triggered in each case ?
@chrif commented on GitHub (Mar 22, 2024):
Below you will find my initial reply, but I found the trigger in production while trying to get the full stack trace. It is the opcache
preload.phpfile that triggers the error. If I commentopcache.preload=/app/config/preload.phpin php.ini, I don't get the error, and if I keep it but setAPP_DEBUG=1, I don't get the error either.Versions
Stack trace for the prod cache clear functional test when it fails with
enable_lazy_ghost_objects: falseIn production when it fails with
enable_lazy_ghost_objects: trueI don't have the full stack trace. If I use APP_DEBUG=true, I don't get the error. If it's not enough, I'll have to figure this out.@stof commented on GitHub (Mar 22, 2024):
Indeed, the new implementation of ProxyFactory does not seem to validate the compatibility of classes at proxy generation time, but only when the proxy class is used.
/cc @nicolas-grekas
@ostrolucky commented on GitHub (Mar 22, 2024):
I guess this is an issue in var-dumper? Shall we close here?
@nicolas-grekas commented on GitHub (Mar 22, 2024):
I think this is for the ORM. VarExporter's lazy objects are compatible with readonly classes. But I'm not sure the ORM takes care of them properly (either failing early or generaton readonly proxies.)
@derrabus commented on GitHub (Mar 26, 2024):
Can you create a reproducer for this issue?
@chrif commented on GitHub (Mar 28, 2024):
I'll make time next week for that.
@beberlei commented on GitHub (Mar 28, 2024):
The error "the Unable to create a proxy for a readonly class" is only triggered when lazy ghost objects is false during
ProxyFactory::generateProxyClasses. There is no other way this exception inside the ProxyGenerator can be triggered, because its from the old code.9d1a4973ae/src/Proxy/ProxyFactory.php (L227-L229)@beberlei commented on GitHub (Mar 28, 2024):
Some hints, A reproducer for the fatal error with lazy proxy should be a test with a readonly class, see
@requires PHP 8.1and other uses in the testsuite to restrict run for php with readonly classes. Call$this->_em->getReference()to create a proxy.