Issue: Cached metadata/generated files

[edward-simpson]

I've been seeing an issue for a while now that I think relates to OPCache and generated metadata. It's not easy to replicate, but usually clears on subsequent deployments.

There are two scenarios I have seen:

• Addition of new plugin, this plugin doesn't fire until after second deployment with no code changes.
• Addition of new extension attributes - new attributes don't get added to generated class even after new deployment, causing site errors, solution has previously been to copy locally generated correct class onto server to replace cap generated file.

I think this is related to OPCaching of generated files, we use the cap opcache tool but this only clears opcache at the end of each deployment

[PascalBrouwers]

I also clear opcache at the end of each deployment. Never ran into any problems with it. Are you sure you are clearing cli AND web opcache?

[edward-simpson]

@PascalBrouwers we flush the web opcache using scripts provided by our (magento specialist) hosting, cli opcache clears after each cli command finishes running, so flushing it manually isn't ever necessary

[PascalBrouwers]

hmm, are you maybe caching the backend with Redis and not using a different cache prefix on your deployment?

[edward-simpson]

@PascalBrouwers interesting suggestion, how do you go about doing this? Doesn't look like there's a documented way of changing the id_prefix by CLI, unless you set it up as an env var?

[PascalBrouwers]

See https://github.com/davidalger/capistrano-magento2/issues/151#issuecomment-769204604 how I do it using capistrano.

[edward-simpson]

@PascalBrouwers interesting thanks, could changing the cache key stop old entries from being flushed + cause Redis (or whatever caching system is being used) to fill up?

[PascalBrouwers]

That's you redis configuration. I suggest using an eviction policy of allkeys-lru or allkeys-lfu.