See also #2916.

If this could be treated with some urgency, we have been unable to upgrade beyond ElasticPress 3.6.6

Since 4.x with Object Cache Pro plugin exhibits run-away Memory Usage whilst indexing

The problem with wp_cache_flush_runtime() as it is right now is that for sites using Redis, for example, it will end up flushing everything that is in the cache, which may cause an undesired side-effect.

One thing we could do is to add a new action at the bottom of the stop_the_insanity() method, let's say ep_sync_stop_the_insanity or similar and add that wp_cache_flush_runtime() call in the other plugin.

@tillkruss is that a change you would like to make? Thanks in advance!

The problem with wp_cache_flush_runtime() as it is right now is that for sites using Redis, for example, it will end up flushing everything that is in the cache, which may cause an undesired side-effect.

That's not correct. Setting $cache to an empty array and calling wp_cache_flush_runtime() is the exact same action.

For your example, Redis data is not touched.

One thing we could do is to add a new action at the bottom of the stop_the_insanity() method, let's say ep_sync_stop_the_insanity or similar and add that wp_cache_flush_runtime() call in the other plugin.

No, it's up to this plugin to manage the object cache. Redis/Memcached plugins only supply the API to communicate with the external object cache.

@felipeelia: For more context, the Action Scheduler plugin had a similar issue: woocommerce/action-scheduler#790

And this is how they solved it using wp_cache_flush_runtime(): woocommerce/action-scheduler#827

Hey @tillkruss,

Thanks for the quick reply. I didn't notice that Redis Object Cache would overwrite the wp_cache_flush_runtime() implementation, so we should be good here.

You made me curious about what you meant with it's up to this plugin to manage the object cache. Do you mean ElasticPress should manage object cache?

I still think it is a good idea to have an action there just to give people the chance to do any extra steps they want but we can take care of that in another PR.

You made me curious about what you meant with it's up to this plugin to manage the object cache. Do you mean ElasticPress should manage object cache?

Sorry, I kept it brief due to being on my phone.

I meant that object caching plugins shouldn't hook into 1000s of actions of other plugins, but rather that each individual plugin should manage its own cache data itself with calls like wp_cache_flush_runtime() and wp_cache_flush_group(). That way me and other authors don't need to keep track of changes in other plugins.

ElasticPress is a bit special (like Action Scheduler), since you're running long tasks.

I still think it is a good idea to have an action there just to give people the chance to do any extra steps they want but we can take care of that in another PR.

That makes sense, I'll add an action to the PR.

That all makes sense @tillkruss, thanks. If you are going to add the action, can you please add @since 4.3.0 to its docblock?

That all makes sense @tillkruss, thanks. If you are going to add the action, can you please add @since 4.3.0 to its docblock?

Added. Feel free to rename of course.