If an administrator triggers cron, a background update could temporarily lock them out
|Reported by:||nacin||Owned by:||nacin|
Thank goodness for local autosaves in 3.6.
If an administrator triggers a cron event, a background update could temporarily lock them out. The first page they open will trigger the cron, and then the very next thing they do will hit the maintenance wall. We could block or delay updates whenever it's a logged-in user that triggers a cron event, but that's kind of lame — especially if the site is only accessible to logged-in users.
I think we should do a few things to mitigate this. In order of priority and ease:
- High priority, pretty simple. We need to test how heartbeat — auth checks, post locks, and interrupted connection notices — handles this. It's possible we need to account for a 503 and say "Hang tight, your site is updating" or something, in lieu of the intermittent connection issue.
- Medium priority, takes a little more work. We should show a notice. "This site is scheduled to update WordPress in less than %s minutes. Update now, it's easy and takes a few moments: (link)". Show it to users capable of updating WordPress core (it's just something we'd add to the existing nag). Say, if we are within 30 minutes of the next scheduled event? Jaquith mocked up a little timer countdown in the toolbar, which could be cool for 3.8.
- Low priority, decent amount of work. If a user with the ability to update_core triggers a cron event that would normally cause a background update, *delay* the update by 30 minutes, and show them said notice. (Do not allow it to be delayed a second time, which we can solve by just passing some random argument to the cron event.) It's not ideal, as they're then told to click something that should be automatic, but it'd be really nice to not interrupt what they are doing (potentially the saving of a post, etc.). It's possible an update could come at a *really* inopportune time, obviously, and we should try to prevent surprises. It's kind of similar to "Install and Relaunch" that a bunch of Mac apps nag me about all the time. Note, this would likely require us to put some one-off code pretty deep into the cron API.
It's possible that this is not a big deal. I don't think I've seen it reported more than once or twice, though both dd32 and I have triggered it on our own. (It should be noted that when dealing with local installs, it will *always* be your visit that triggers the cron, so it's more likely to be noticed.)
Why? It's possible/probable that the download and unzipping takes most of the time (we're seeing averages of about 24 seconds for nightly builds) and that we only have maintenance mode set for a few seconds.
We currently have data on how long an update takes, but we should specifically try to collect a better data point: exactly how long maintenance mode was set for. (We should be able to do this by including the file before we leave maintenance mode and retrieve the time that was set.) Such a short timeframe might actually render this ticket moot, as the person's page will be loading by the time the cron HTTP request is fired, and maintenance mode will be off again by the time the person tries to advance to the next page.
Change History (15)
- Owner set to nacin
- Resolution set to fixed
- Status changed from new to closed