Environment<\/strong><\/p>\n\n\n\n Symptom<\/strong><\/p>\n\n\n\n WooCommerce \u2192 Status \u2192 Scheduled Actions: Almost every failed row is the same hook. The log for each one is identical: Action Scheduler itself seems healthy : 2,146 actions from other plugins complete normally.<\/p>\n\n\n\n Possible root cause<\/strong><\/p>\n\n\n\n The callback is registered inside an admin-only code path, but Action Scheduler executes it in a non-admin context.<\/p>\n\n\n\n In And in During a Why it loops forever<\/strong><\/p>\n\n\n\n Action Scheduler correctly applies its own safety brake (“A new instance will not be scheduled”), but It is hooked to The row is supposed to run weekly. In practice new rows appear every few minutes while I browse wp-admin. I also see duplicate rows sharing the same claim ID (e.g. Why this may not reproduce on your test sites<\/strong><\/p>\n\n\n\n You may not be able to reproduce it on your side because of the cron-job setup.<\/p>\n\n\n\n Impact<\/strong><\/p>\n\n\n\n Beyond the noise, the Suggested fix<\/strong><\/p>\n\n\n\n Do you think that registering the Action Scheduler callback outside the Thanks for you help !<\/p>\n\n\n\n <\/p>\n","protected":false},"template":"","class_list":["post-19005235","topic","type-topic","status-publish","hentry"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/topic\/19005235","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/topic"}],"about":[{"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/types\/topic"}],"version-history":[{"count":0,"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/topic\/19005235\/revisions"}],"wp:attachment":[{"href":"https:\/\/wordpress.org\/support\/wp-json\/wp\/v2\/media?parent=19005235"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
define( 'DISABLE_WP_CRON', true );<\/code> in wp-config.php<\/code>, with an external cron service calling \/wp-cron.php<\/code> every 10 minutes<\/li>\n<\/ul>\n\n\n\n
All (11,341) | Canceled (13) | Complete (2,146) | Failed (9,162) | Pending (20)<\/p>\n\n\n\n<\/figure>\n\n\n\n
1. action created
2. action started via WP Cron
3. action failed via WP Cron: Scheduled action for cartflows_update_knowledge_base_data will not be executed as no callbacks are registered.
4. This action appears to be consistently failing. A new instance will not be scheduled.<\/p>\n\n\n\nclasses\/class-cartflows-loader.php<\/code>, the file holding the callback is included only in admin:
if ( is_admin() ) { include_once CARTFLOWS_DIR . ‘classes\/class-cartflows-admin.php’; }<\/p>\n\n\n\nclasses\/class-cartflows-admin.php<\/code>, init_hooks()<\/code> bails out again before registering anything:
public function init_hooks() { if ( ! is_admin() ) { return; } \/\/ … add_action( ‘init’, array( $this, ‘run_scheduled_docs_job’ ) ); add_action( ‘cartflows_update_knowledge_base_data’, array( $this, ‘cartflows_update_knowledge_base_data’ ) );<\/p>\n\n\n\n\/wp-cron.php<\/code> request is_admin()<\/code> returns false<\/code>, so the class is never loaded and add_action( 'cartflows_update_knowledge_base_data', ... )<\/code> never runs. Action Scheduler finds no callback and fails the action as the log states.<\/p>\n\n\n\nrun_scheduled_docs_job()<\/code> defeats it:
public function run_scheduled_docs_job() { if ( false === as_next_scheduled_action( ‘cartflows_update_knowledge_base_data’ ) && ! wp_installing() ) { as_schedule_recurring_action( time(), WEEK_IN_SECONDS, ‘cartflows_update_knowledge_base_data’ ); } }<\/p>\n\n\n\ninit<\/code> in the admin. Because the previous action ended as failed<\/code> rather than pending<\/code>, as_next_scheduled_action()<\/code> returns false<\/code>, so a brand-new recurring action is created on every admin page load<\/strong>. The cycle seems to be:<\/p>\n\n\n\n\n
809269<\/code>, 809287<\/code> each appearing twice), which suggests concurrent admin requests racing in run_scheduled_docs_job()<\/code>.<\/p>\n\n\n\nwp_actionscheduler_actions<\/code> and ..._logs<\/code> tables grow without bound (over 11,000 rows for me). My database was under memory pressure, so this is a real cost for me.<\/p>\n\n\n\nis_admin()<\/code> guard, since Action Scheduler is not an admin-only subsystem could work ? It would also be nice to have run_scheduled_docs_job()<\/code> respect Action Scheduler’s “consistently failing” state instead of unconditionally recreating the action whenever none is pending.<\/p>\n\n\n\n