Giters

Automattic / Cron-Control

A fresh take on running WordPress's cron system, allowing parallel processing

Home Page:https://wordpress.org/plugins/wp-cron-control/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Inconsistent handling when disable event-execution in multisite

ethitter opened this issue · comments

commented

Under a multisite, only the main site is checked to trigger the runner's backoff functionality, but each subsite can disable its execution independently. The runner's CLI commands respect the value for individual sites, but the runner's backoff isn't triggered by subsites.

Under multisite, either the option to disable automatic execution should be an instance-wide control (site option), or the runner should be updated to handle individual subsites differently than they are now. The orchestrate runner-only get-info command will likely need to be updated too.

commented

I'm thinking probably both for multisites.

A site option (network-level) can exist to disable the runner network-wide. If set, wp cron-control orchestrate runner-only get-info will first return that it's disabled and the runner will not go on to request a list of sites: https://github.com/Automattic/cron-control-runner/blob/7504e921e06595bf2b0e0fc97febdd1aed4c0369/performer/cli.go#L77-L88 (thus removing all siteWatcher goroutines).

And then a normal subsite-level option can exist for disabling on just a specific subsites. Can then either:

  1. have the orchestrator's "sites list" cli exclude returning disabled sites
  2. or just rely on the getEvents cli always returning an empty list for the runner.

The first would be expensive on the listing command, but maybe cheaper overall since it prevents the runner from calling getEvents perpetually/unnecessarily.

It's also probably worth taking an overall look at this feature. Currently we use it via a filter during "data syncs" between environments, to prevent cron from running until various cleanup operations take place to remove certain prod data from child sites. But notably - there's no known usage/desire to just shut cron off completely on a site that I am aware of.

In fact, this may be undesirable if there becomes some essential internal events for example. Maybe worth stripping down the functionality a bit and just have it work via filters rather than the options setup?