UnexpectedValueException: tree metadata about stofdoctrineextensionsbundle

[stof]

Are you using the extension in a mapped superclass ? If yes, this is likely the same issue than #455 (for a different extension but the bug in gedmo/doctrine-extensions affects all extensions)

[hual7]

Are you using the extension in a mapped superclass ? If yes, this is likely the same issue than #455 (for a different extension but the bug in gedmo/doctrine-extensions affects all extensions)

@alexander-schranz
Could you please answer? Thx.

[alexander-schranz]

@stof Yes it are mapped-superclass and usage of the ResolveTargetListener: https://github.com/sulu/sulu/blob/e1e8f45735f569417db027171fc1267fc29e7e13/src/Sulu/Bundle/PersistenceBundle/DependencyInjection/Compiler/ResolveTargetEntitiesPass.php#L50-L51.

Do you have an example of the cache configuraiton you mention in: #455 (comment)

Could not find something in the recipe: https://github.com/symfony/recipes-contrib/blob/main/stof/doctrine-extensions-bundle/1.2/config/packages/stof_doctrine_extensions.yaml

[stof]

@alexander-schranz as for any other bundle, you can use bin/console config:dump stof_doctrine_extensions to dump the available configuration of the bundle. the configuration of the metadata cache is done through metadata_cache_pool

[alexander-schranz]

@stof What confuses me more is what value to use, as there is in the doctrine recipe not longer a doctrine metadata cache pool, which I first thought I could just configure that in stof extension. But that was as I thought removed some time ago and only result and system cache for query cache exists now: https://github.com/symfony/recipes/blob/main/doctrine/doctrine-bundle/2.10/config/packages/doctrine.yaml

I debugged now how doctrine is handling it in the bundle it seems like they go on kernel.debug flag here: https://github.com/doctrine/DoctrineBundle/blob/f9d59c90b6f525dfc2a2064a695cb56e0ab40311/DependencyInjection/DoctrineExtension.php#L1055

Seems like its not a cache pool used by doctrine itself for the metadata, atleast it doesn't looke for me like a PSR6 cache pool?

Would it make sense that the stof extension bundle handles the things the same that on kernel.debug: false it register an own metadata cache pool automatically and on true it doesn't?

For current state the system cache pool seems atleast not run into that issue but only should configured in when@prod (our case also stage) as it does not exist on dev:

when@prod:
    stof_doctrine_extensions:
        # fix issue with gedmo/extensions 1.8.0 and stof/doctrine-extensions-bundle: 3.12.0
        # @see https://github.com/stof/StofDoctrineExtensionsBundle/issues/457
        metadata_cache_pool: doctrine.system_cache_pool

For Sulu users:

when@prod: &prod
    stof_doctrine_extensions:
        # fix issue with gedmo/extensions 1.8.0 and stof/doctrine-extensions-bundle: 3.12.0
        # @see https://github.com/stof/StofDoctrineExtensionsBundle/issues/457
        metadata_cache_pool: doctrine.system_cache_pool

when@stage: *prod

[alexander-schranz]

Today I did run into an own project also into this issue but in my case the change of the metadata_cache_pool didn't help it the error is a different one now:

[2023-07-18T18:05:57.160555+02:00] php.CRITICAL: Uncaught Error: Failed opening required '/var/website/releases/296/var/cache/website/stage/doctrine/orm/Proxies/__CG__SuluBundleSecurityBundleEntityUser.php'

Seems also be related so to the ResolveTargetListener as that class / Proxy should not exist as it was Replaced by AppDomainModelUser.php 🤔 . Sadly I can not yet reproduce it locally so maybe only happens when no @dev dependencies are here. I will try to do that next after fixing the prod server.

Update: Okay the new error was unrelated to this issue. The old class was still in the SessionStorage of Symfony after cleering the session it did work in my case.

[andriusvo]

Can confirm this issue