Cron jobs not working with Object cache enabled

Hello @son9ne

Thank you for reaching out and for your post with detailed explanations.
I’ve tried to check this immediately, however, I cannot seem to replicate the issue in our environments.
Let me do some more testing and try to replicate the problem and I’ll get back to you with more information.

Thanks!

I can confirm this happens locally but it seems to take a week for this to start to happen. That is what’s so puzzling about this. I would expect this to happen immediately. I am still trying to dig into this issue but got pulled off on another task real quick. I will update this post when I find anything.

I am also trying to setup a vanilla setup for this since we do have a lot of plugins installed (mostly custom plugins for our system that won’t affect how W3TC works but we do have WPML and WooCommerce installed too). What is weird, is that I can resolve the issue by making sure the object-cache.php file is removed.

Our production system won’t remove files (other than cache) so when we were disabling the object cache, the file still existed. Once I removed the object-cache.php, then cron works as expected.

Thank you for looking into this issue. I can tell that time is a factor for this to break cron. I will update when I find out more information.

• This reply was modified 1 year, 11 months ago by SoN9ne.

Hello @son9ne

Thank you for your feedback.

Can you please let me know if the problem is with all cron jobs or just W3TC cron jobs?
Are using a native wp-cron or custom server cron job?

Thanks!

Still not able to isolate this issue. Once I remove the object-cache.php file then add it back, I need to wait some time until this happens. I will keep trying to figure this out.

I am running wp cron event run --due-now at 5 minute intervals. With these constants:
define('DISABLE_WP_CRON', true);
define('WP_CRON_LOCK_TIMEOUT', 60);

The hard part is debugging with wp cli.

As for how these crons are invoked, on production, we are using AWS ECS Scheduled tasks that runs the wp cron command on 5 minute intervals. On local development, we manually trigger the wp cron command. This happens on production and local.

On production, we need to use ECS Scheduled tasks as using the URL to trigger cron will cause issues due to autoscaling (it will kill the task running the cron and we had this issue previously).

The cron jobs affected are all cron jobs and it’s rarely the same that keep running when this happens. This is why I am assuming the cron option is being cached. After some time, it’s only the same cron jobs that keep running while all other are overdue. I then remove the object-cache.php file and then disable the object cache and this seems to recover as the cron jobs will run immediately after I do this.

I have WP Crontrol installed and when I check the list, I see almost all cron jobs are a week overdue. This time this happened, the cron jobs that kept running were:
wpseo_ping_search_engines
wc_admin_unsnooze_admin_notes
wp_privacy_delete_old_export_files
olyott-plugin-importexport-cron-queue-process
action_scheduler_run_queue

The previous time this has happened, this was completely different crons that kept running.

On local, I have tried to use the URL to invoke cron and the same issue is happening. Since I removed the object cache file, it takes some time for this to happen again. Once this happens again, I can debug using the URL for the cron process. I am waiting for this to happen again to get more information. Until then, it’s impossible to duplicate the issue.

One more thing that I am noticing now that I am paying attention to the cron system. When this issue happens, it seems that when the crons do run and object cache is enabled, I am seeing single run crons still showing after they ran. Meaning, that crons that ran do not appear to be shown as being updated for the next run time. When checking the database, I see them in the cron options table too. That is interesting. When I disable the object-cache.php file, when they run again, they do get updated properly and the single run crons are removed properly.

Let me know if you need more information.

Thanks again

• This reply was modified 1 year, 11 months ago by SoN9ne.
• This reply was modified 1 year, 11 months ago by SoN9ne.

Hello @son9ne

Thank you for providing the details.
I’ll bring this to the team and we’ll try to replicate the problem. If the problem can be replicated I’ll create a Github issue on your behalf.
Thank you for your patience.
Thanks!

To add more details about what is happening:

When I run the cron, the same crons are running over and over again on each cron interval. When I remove the object-cache.php file, then run the crons, they work as expected and update the cron options value appropriately (all cron timestamps are updated and single run crons are properly removed).

If I add the object-cache.php file back, then run cron again, it will run the same cron jobs as before I removed the object-cache.php file and then it will update the cron option with the cached values it already ran with. This is adding back into the cron setting, single run crons that have already ran as well as adding back in bad next runtimes. This is also causing all crons to show as overdue in WP Crontrol page.

It would seem (cannot check this in code yet), that the object-cache.php file, for whatever reason, is only using the cached value of the cron options value and not fetching it appropriately. Given my default cache lifetime is 180 I would expect it to expire after that time. I do have the Store transients in database unchecked. I wanted to make note of this for now.

There is a direct correlation between the same crons running, the bad cron options values, and the object-cache.php file. Simply removing that file stops this from happening. I don’t need to change any settings, just removing that file fixes the issue. I am unaware of the consequences of keeping that file removed. I assume W3TC will not cache properly with that file removed. So I am still attempting to figure this out.

I tried to add config to the Non-persistent groups since this is supposed to ignore caching for this group, but that has no affect.

I will update more as I discover more about this issue.

• This reply was modified 1 year, 11 months ago by SoN9ne.

I have created a ticket for this issue on github: https://github.com/W3EDGE/w3-total-cache/issues/605

I have now been able to duplicate this on a vanilla WP setup consistently.

This appears to be a bigger issue of the Object Cache not properly invalidating options when being updated. Which is a severe bug as this can cause serious issues on a site.

Please share this with the devs: https://github.com/W3EDGE/w3-total-cache/issues/605#issuecomment-1357749152

That shows exactly how to duplicate the issue and also shows how I was able to bypass the issue (not a proper fix).

The concern is that this is a core issue with Object Cache and this is affecting all options in WP (possibly other systems?) . For now, I cannot use this on PROD due to it not updating the cache for any options

• This reply was modified 1 year, 11 months ago by SoN9ne.

Hello @son9ne

Thank you very much for all the details you provided.

This will be investigated and one of our devs is already assigned to this ticket.

Thank you for bringing this up and thank you for your patience.