cartflows_update_knowledge_base_data => 10K tasks failed

Hi all,

I’m reporting a problem that has generated 9,162 failed scheduled actions on my production store. The failure is not intermittent as the action has never once succeeded.

Environment

• CartFlows 3.2.0 (free)
• WordPress 7.1 / PHP 8.4 / WooCommerce
• define( 'DISABLE_WP_CRON', true ); in wp-config.php, with an external cron service calling /wp-cron.php every 10 minutes

Symptom

WooCommerce → Status → Scheduled Actions:
All (11,341) | Canceled (13) | Complete (2,146) | Failed (9,162) | Pending (20)

Almost every failed row is the same hook. The log for each one is identical:
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.

Action Scheduler itself seems healthy : 2,146 actions from other plugins complete normally.

Possible root cause

The callback is registered inside an admin-only code path, but Action Scheduler executes it in a non-admin context.

In classes/class-cartflows-loader.php, the file holding the callback is included only in admin:
if ( is_admin() ) { include_once CARTFLOWS_DIR . ‘classes/class-cartflows-admin.php’; }

And in classes/class-cartflows-admin.php, init_hooks() 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’ ) );

During a /wp-cron.php request is_admin() returns false, so the class is never loaded and add_action( 'cartflows_update_knowledge_base_data', ... ) never runs. Action Scheduler finds no callback and fails the action as the log states.

Why it loops forever

Action Scheduler correctly applies its own safety brake (“A new instance will not be scheduled”), but run_scheduled_docs_job() 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’ ); } }

It is hooked to init in the admin. Because the previous action ended as failed rather than pending, as_next_scheduled_action() returns false, so a brand-new recurring action is created on every admin page load. The cycle seems to be:

1. Admin page load → no pending action → schedule a new one
2. WP-Cron runs it → no callback registered → fail
3. Action Scheduler refuses to reschedule
4. Next admin page load → back to step 1

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. 809269, 809287 each appearing twice), which suggests concurrent admin requests racing in run_scheduled_docs_job().

Why this may not reproduce on your test sites

You may not be able to reproduce it on your side because of the cron-job setup.

Impact

Beyond the noise, the wp_actionscheduler_actions and ..._logs tables grow without bound (over 11,000 rows for me). My database was under memory pressure, so this is a real cost for me.

Suggested fix

Do you think that registering the Action Scheduler callback outside the is_admin() guard, since Action Scheduler is not an admin-only subsystem could work ? It would also be nice to have run_scheduled_docs_job() respect Action Scheduler’s “consistently failing” state instead of unconditionally recreating the action whenever none is pending.

Thanks for you help !