Open KDederichs opened 2 weeks ago
IndraGunawan
commented
2 weeks ago i can't reproduce it
if i do inject the non-exist env-var which is a typo, I get the same error as yours. make sure there is no typo on the env-var name or can you create a minimal reproducer for it?
KDederichs
commented
2 weeks ago I deployed it twice, with the only difference being the EA route config enabled in one deploy (failed one) and it being disabled in the second one (successful one).
I'll see if I can build a reproducer though
IndraGunawan
commented
2 weeks ago i tried to remove EA routes config but still have non-exist env-var, there's no error while cache clear but I get 404 while accessing the page where I do inject the service. can you confirm this?
KDederichs
commented
2 weeks ago https://github.com/KDederichs/sf-reproducer/tree/ea/env
There you go.
run docker compose exec php bin/console cache:clear with it enabled produces the error, with it disabled it doesn't.
While writing this I also found the cause, I do not have that secret set in dev mode (only prod).
The issue here is though that it'll run the cache:clear on composer install in dev mode which will in turn cause this error to happen since it seems to try and instantiate all the routes on cache clear for some reason.
IndraGunawan
commented
2 weeks ago yes, having the env-var on prod only and composer install on dev will raise the error.
glad that you found the cause
KDederichs
commented
2 weeks ago It shouldn't raise that error though is my point. It didn't before and shouldn't start doing so now
IndraGunawan
commented
2 weeks ago the title should be
"Pretty URL Router fails to clear cache in DEV if ENV var only exists in PROD"
because it won't be an issue if you do clear cache on the correct environment
AFAIK. in the previous version. the crud controller is registered to the service container but it has not been initialized because it is not being used anywhere in the cache warmup since 4.14 EA has its route loader that is being called in cache warmup which iterates all the crud controllers hence it will throw an error if the controller can not be initialized, IMO nothing easyadmin can do here
KDederichs
commented
2 weeks ago AFAIK you can't tell composer to clear the cache after install in prod mode though? At least I've never seen it. Normal cache clear isn't the issue I could do that with env=prod sure. Issue is when it's triggered by composer after installing the dependencies.
IndraGunawan
commented
2 weeks ago you can't tell composer to clear the cache after install in prod mode though?
you can, do check https://symfony.com/doc/current/deployment.html#c-install-update-your-vendors on the orange caution box
javiereguiluz
commented
2 weeks ago Note: we don't generate/cache the routes in a cache warmer ... we cache the routes (using this method: https://github.com/EasyCorp/EasyAdminBundle/blob/4.x/src/Router/AdminRouteGenerator.php#L373-L398) after generating them in the custom route loader.
We use cache.system as the cache, but not directly: https://github.com/EasyCorp/EasyAdminBundle/blob/8c88ce12d343452a090be7e67e758fcf1a558f0b/src/Resources/config/services.php#L204-L206
Describe the bug Pretty URL router doesn't seem to like env vars that are stored in secrets (https://symfony.com/doc/current/configuration/secrets.html). When enabling the new router deploys will fail with the error below. To Reproduce
Inject a Service that relies on an env that's stored in a secret into a CRUD controller via constructor.
(OPTIONAL) Additional context