Async actions get stuck in ‘past-due’

Hi @jamminjames

Thanks for the detailed info. I know how frustrating this kind of thing can be.

If your async actions are getting stuck in past-due but run fine manually, it usually means the async runner isn’t being triggered properly. Even if your site’s cron is firing every minute, Action Scheduler’s async queue uses a separate request behind the scenes:

/wp-admin/admin-ajax.php?action=as_async_request_queue_runner

If that request gets blocked or fails silently, the jobs will just sit there.

Few thing I’d suggest checking:

• Try visiting that URL in your browser while logged in. Does it run or show an error?
• Look in your server error logs for anything related to admin-ajax.php
• Disable any security/firewall plugins temporarily (Wordfence, iThemes, etc.) and test again.

That said, if you want to trigger the async queue manually for testing, here’s a quick snippet you can run once from a custom plugin or via WP CLI:

do_action( 'action_scheduler_run_queue', 'Async Request' );

Let me know if this helps or if you have any follow-up questions.

Hey @jamminjames

Thanks for checking all that and sharing additional details.

That URL /wp-admin/admin-ajax.php?action=as_async_request_queue_runner needs to be hit by anonymous requests. A 403 usually means something (server, plugin, firewall) is blocking it. Since you’ve ruled out Cloudflare and Wordfence, here are a few more places to check:

• Look for any custom code or mu-plugins restricting access to admin-ajax.php. Especially anything that calls is_user_logged_in() and dies for anonymous users.
• If your host runs a WAF (even separate from Cloudflare), it may be blocking non-browser traffic to admin-ajax. Worth checking with them.
• Try hitting that URL using cURL with a standard user agent:

curl -A "Mozilla/5.0" -I "https://yoursite.com/wp-admin/admin-ajax.php?action=as_async_request_queue_runner"

If that gets a 200, but your cron job doesn’t, it’s likely a user-agent or header issue.

Can I just run that every time we want to use async?

Yes, calling do_action( 'action_scheduler_run_queue', 'Async Request' ); manually works as a workaround. You can even hook it into a scheduled action or CLI command. For example:

if ( defined( 'WP_CLI' ) && WP_CLI ) {
    add_action( 'init', function() {
        do_action( 'action_scheduler_run_queue', 'Async Request' );
    } );
}

Keep in mind that it runs jobs in the current process, so if those image downloads are heavy, PHP timeouts could kick in. For that, wp action-scheduler run via CLI is safer.

Let me know what you find in those config checks.

Hi @jamminjames

That looks like it belongs to a plugin called “WordPress File Upload Pro.” Could the cookie interfere somehow? 

It (wp_wpfileupload_*) shouldn’t interfere with Action Scheduler’s async requests. That cookie is specific to file upload functionality.

One thing I noticed is that if I deactivate the custom plugin that creates the as_enqueue_async_action and has the callback, the past-due actions go through, with a “no callback” error, of course. Does the fact that they go through at that point mean anything?

Yes, it is quite telling. This suggests the issue isn’t with Action Scheduler’s core async request mechanism but rather with how the async request interacts with your custom plugin’s callback registration.

That’s not the case if we can run as_enqueue_async_action successfully the usual way, right? 

Yes, you’re correct. When running this way:

• It runs in the current process, so PHP timeouts could be an issue for your image downloads.
• It doesn’t have the benefits of Action Scheduler’s async processing.

For troubleshooting, you could try this temporary solution to bypass the async request mechanism:

add_filter( 'action_scheduler_allow_async_request_runner', '__return_false' );

This filter will force Action Scheduler to use the WP Cron runner instead of async requests. However, please note:

1. This is a temporary debugging step, not a long-term solution.
2. It will affect ALL async actions in your site, not just your image downloads.
3. Long-running tasks may still hit PHP timeouts since they’ll run in the main process.

If this filter resolves the issue, it confirms the problem is specifically with the async request mechanism rather than the action registration or callback. However, given your need to handle large image downloads, you should still work on fixing the root cause of the 403 errors rather than entirely disabling async requests.

That said, would you be able to share:

• When exactly do the actions get stuck in past-due? Right after creation or after some time?
• Are there any patterns in which images fail vs succeed?
• Do you see any relevant entries in your server’s error logs when this happens?

This will help me better understand the root cause rather than just working around it.