[wp-hackers] Dealing with WP cron's raciness

[David Anderson]

Dion Hulse (dd32) wrote:
> I just wanted to point out, that doing this bypasses the major component of
>   WP Cron which attempts to allow things to only run once.. doing so you'll
> almost be guaranteed to have duplicate events fired.
>
> When WordPress fires off the cron, it creates a locking transient (which
> should be pretty reliable when using an external object cache, not awesome,
> but still pretty good, when not) which is based on microtime(true) which
> includes microseconds: 1379596515.2753798961639404296875
> The request is then made via
> wp-cron.php?doing_wp_cron=1379596515.2753798961639404296875. If the GET arg
> doesn't match exactly what's in the transient, that request doesn't perform
> any operations.
Hi Dion,

Thanks for the feedback... I mentioned before a couple of things:

1) My motivation is to torture-test the worst-case scenarios, because 
they are what generate support requests. A significant number (i.e. 
significant enough to generate a flow of support requests, once you have 
5,000 new installs a week) of hosting companies disable this mechanism 
(in part, through disabling loopback HTTP connections), and instruct 
their users to call wp-cron.php directly (via a scheduler in their 
control panel). (I know that's "non-optimal". I know about 
ALTERNATE_WP_CRON - as I say, I'm trying to deal with what users are 
doing and likely to keep on doing, not what they ought to do).

2) I said before to Otto that from my reading of the code in 
wp-cron.php, there's also an attempt to apply the same locking mechanism 
you describe above in there. The only difference is that the loopback 
HTTP introduces a slightly random timing delay, which fortuitously gives 
the time delay needed for the locking mechanism to work - i.e. the 
effect is a side-effect of the method,rather than procured directly by 
it. Am I reading that wrong?

Paul Menard wrote:

> I actually have reasons in the past to rely on the multi-instance cron processing for some sampling plugins I wrote. Each instance needed to be independent. I don't want WP to be the traffic cop.
If you need to *rely* upon an action running twice, then surely you 
should just schedule two actions? Note that I wasn't suggesting locking 
at the *individual action* level but at the *cron queue processor* level.

Best wishes,
David

-- 
WordShell - WordPress fast from the CLI - www.wordshell.net