Past Due actions not processed

[ironicmoka]

I'm having a bit of a problem debugging this issue.

WP Cron is adding actions to the queue (pending) without problems.
When the scheduled time arrives, the actions move to the past-due status.

I'm having a hard time identifying the cause of these behaviors:

• For all actions, clicking "Run" in the backend Action Scheduler runs the actions almost instantly, and I can see them listed under the "Completed" status filter.
• Trying to run action-scheduler via WP Cli wp action-scheduler run prompt me with 0 batches executed. Success: 0 scheduled tasks and there are no status changes in the backend (or in the database).
• Trying to run a single action via wp-action scheduler action run and passing the action ID processes the action almost instantly, and the update is reflected in the backend with that action listed as "Completed".
• Trying to run a single action via backend under Tools > Action scheduler also processes the action almost instantly, and the update is reflected as "Completed".
• wp action scheduler action list retrieves everything correctly for all statuses except "past-due": it shows an empty table even though there are Past due actions in the backend (and those actions can be processed via CLI by passing their ID).

I've tested this on different hooks and groups with the same results.

I'm running a WooCommerce store on a VPS with both Varnish and Redis and various plugins. However, the same behavior occurs if I make a local copy of the website with no caching whatsoever and deactivate all plugins (except for WooCommerce) and the theme.

I think this might be related to #1041; it looks quite similar even though we're not using WooCommerce Subscriptions on this site, and I can manually trigger single actions.

I also see slow queries (taking even 10 seconds) in the database, such as:

INSERT INTO wp_actionscheduler_claims (date_created_gmt) VALUES (datetime)

or

SELECT p.ID FROM wp_posts p INNER JOIN wp_term_relationships tr ON tr.object_id=p.ID INNER JOIN wp_term_taxonomy tt ON tr.term_taxonomy_id=tt.term_taxonomy_id INNER JOIN wp_terms t ON tt.term_id=t.term_id AND t.slug=s WHERE post_type=s AND p.post_title=s AND p.post_content=s AND p.post_status IN (s) ORDER BY p.post_date_gmt ASC LIMIT 0, 1

But what's puzzling me is why running single actions via CLI and the backend works (instantly) while batch processing does not.

I'm guessing it could be related to how timestamps are handled (most slow queries seem to involve GMT), but if so, why is it reliable when actions are changing status from pending to past-due but not when they should be fired? Also, why are past-due actions fetched correctly in the backend but not by WP CLI?

The server time is UTC, both on production and locally

[ironicmoka]

Two follow-up pieces of information:

• I only just noticed that --status=past-due is not a valid argument for wp action-scheduler action list so it's correct that it returns empty. wp action-scheduler action list --status=pending actually fetches both pending and past-due actions (as the latter is just a pending action scheduled in the past).
• running wp action-scheduler action run $(wp action-scheduler action list --status=pending --format=ids) works, but obviously I'm unable to differentiate which action runs based on the timestamp, so I won't be using it on the production site as a workaround.

This leads me to suspect that the time evaluation is the culprit, but I don't know how to debug further.

I've tried testing different PHP versions (from 7.3 to 8.3) and changing the WordPress local time (but I guess that doesn't affect how timestamps are saved in the database).

Trying to sample an action, the raw datetime values inside the database are:

• for scheduled_date_gmt 2025-05-20 16:43:46
• for scheduled_date_local 2025-05-20 18:43:46
• for complete actions last_attempt_gmt and last_attempt_local are populated similarly, for pending are NULL

[tommywo]

I have just stumbled on an issue where wp action-sheduler run didn't pick up pending actions. We figured out that action scheduler does an insert to the database and select right away, however we configured proxysql to route select queries to read replica, which has a small lag, hence no action claims were found. The solution was to route queries to action scheduler tables to writer instance only. Perhaps you see the same issue?