Add async request chaining to default runner (or a new runner)

[thenbrent]

The default Action Scheduler queue runner currently works by scheduling a hook with WP-Cron, then processing a batch of X actions when that hook is triggered. This works well for small queues, but not large queues because the lag between WP Cron requests can slow down the batch processing.

This is especially problematic when:

1. running on a host with a short timeout limit, e.g. Handle hosts with hard timeouts better #108, meaning only small batches can be run at a time; or
2. another plugin or plugins on the site are also using WP Cron which is clogging WP Cron's queue, meaning for example, even if WP Cron is initiated every minute, Action Scheduler may only have its hook called once every 5 minutes

WP CLI

To workaround these issues, we have a WP CLI queue runner which allows the use of WP CLI to avoid any lag between processing batches. This works really well, but also requires WP CLI (and ideally, WP CLI to be scheduled).

Async Request Chaining

A good workaround that can work on many hosts is to use async requests to process jobs.

The basic idea here is to make a request back to the server/site to initiate processing on a new batch once an existing batch has processed or reaches a certain time limit (and been terminated).

State of Async Request Chaining with WordPress

The trouble with this, and the reason Action Scheduler doesn't do it yet, is because it's difficult to achieve the type of reliability we require to process payments across varied infrastructure.

There are many background processing libraries, including one in WooCommerce core.

AFAIK, they all have open issues, and despite often those issues being shared between them, the fixes that are developed are not being pushed back to other libraries (or in some cases where they are submitted, they are ignored by the maintainer/s), meaning there is no canonical, flawless way to run background jobs yet.

Action Scheduler and Async Request Chaining

The above issues don't mean we can't introduce async requests as part of Action Scheduler, but it does mean we can't rely on them (and perhaps even, we shouldn't default to use them).

Eventually, it will be worth auditing the libraries from Techcrunch, A5hleyRich, SkyVerge and WooCommerce core team to attempt to create a library for async request chaining that includes fixes for all of the issues each of those libraries have separately addressed, and aggregating them into one library for use in Action Scheduler to speed up queue processing when WP CLI is not available.

[JPry]

I just wanted to note that I have experience with the Techcrunch Async library, having used it for projects in the past.

[thenbrent]

An interesting issue with request chaining came up in WooCommerce Slack recently - once the initial request commences, there is no way to terminate the process.

This is different to Action Scheduler, where you can just unschedule or cancel the next scheduled action in the sequence.

As an example of the implications of this, if you're deleting data, say for GDPR, and accidentally trigger it, it won't stop until all data is deleted when using request chaining, vs. being able to mitigate it with AS.

As this issue proposes doing the request chaining on the queue runner, that wouldn't be an issue here, because it would just be running over scheduled actions still, but it might be worth documenting in some capacity that one action per piece of data vs. one action for the task to act on all data is a better approach.

[thenbrent]

Closing this for now. I'd like to see this implemented, as it will speed up the default runner, but it's not a priority for now and WP CLI is working great where faster processing is required. We can reopen if it makes sense in future to work on it.