Tom Cafferkey

We are already aware of this issue and released a fix in 9.8.3 yesterday. I suspect these scheduled actions were getting queued up prior to yesterdays release which prevents further ones getting added.

My suspicion is that the wp_actionscheduler_actions table will have many duplicate actions for the hook wc_delete_related_product_transients_async with the same args if you want to confirm this suspicion that would be great.

The following SQL commands should help, if required please replace the wp_ prefix in the table names if they’re different in your own.

Important: Please do this in a staging environment first. Not production.

This command will SELECT all of the duplicate pending scheduled actions for the hook wc_delete_related_product_transients_async

SELECT t1.*
FROM wp_actionscheduler_actions t1
INNER JOIN wp_actionscheduler_actions t2
WHERE 
    t1.action_id > t2.action_id 
    AND t1.hook = 'wc_delete_related_product_transients_async'
    AND t2.hook = 'wc_delete_related_product_transients_async'
    AND t1.status = 'pending'
    AND t2.status = 'pending'
    AND t1.args = t2.args;

If you have duplicate actions here you may want to export/save their action_ids so we can also delete them from the wp_actionscheduler_logs table too.

This command will DELETE all of the duplicate pending scheduled actions for the hook wc_delete_related_product_transients_async

DELETE t1 FROM wp_actionscheduler_actions t1
INNER JOIN wp_actionscheduler_actions t2
WHERE 
    t1.action_id > t2.action_id 
    AND t1.hook = 'wc_delete_related_product_transients_async'
    AND t2.hook = 'wc_delete_related_product_transients_async'
    AND t1.status = 'pending'
    AND t2.status = 'pending'
    AND t1.args = t2.args;

And if you have saved the action_id‘s from the SELECT command you can then cleanup the wp_actionscheduler_logs table:

DELETE FROM wp_actionscheduler_logs
WHERE action_id IN (123, 456, 789);

I must stress again though please do this in a staging environment first.

Since the release of 9.8.3 this should not continue to happen, but please let us know if it does.

@telesante I have merged the PR above which should be released in WooCommerce 9.6 on Jan 20th.

It will still log the warning if its legitimate, however it will only do so once per day.

Hopefully this coupled with the comments above will help solve your problems!

@telesante I have proposed a change to improve the log warnings to only happen once a day maximum. Should this be accepted and merged, it will be in WooCommerce 9.6 due to be released on January 20th

https://github.com/woocommerce/woocommerce/pull/53665

I suspect you’re getting this error because there is a plugin conflict. I notice in an earlier post you mentioned having 48 plugins on your site. Since this is quite a large amount of plugins there is a good chance that one (or a combination) of these plugins are responsible for the above error and/or the erroneous logging that is happening.

As has been mentioned above, it might be beneficial to conduct a full conflict test. You can do this by disabling all other plugins, except WooCommerce. Should the issue persist, you can try switching to a default theme like Storefront. You can find further details on running a full conflict test from this guide.

The result of this test should help us narrow down some factors that are contributing to these problems you’re having.

Thanks @telesante, can you please install the plugin Transient Manager (https://ww.wp.xz.cn/plugins/transients-manager/) and in Tools > Transient Manager do a search for the transient name ptk_patterns

Please paste the value of this transient as a reply.

Hi all,

Thanks for your patience, and again for reporting the issue. I can confirm the issue was with WordPress versions 6.1.1 and before, coupled with WooCommerce Blocks 10.0.1

We’ve just rolled out WooCommerce Blocks 10.0.2 which resolves this issue, so please go ahead and update if you can.

Apologies for any inconvenience caused by this.