[wp-trac] [WordPress Trac] #25660: If an administrator triggers cron, a background update could temporarily lock them out

[WordPress Trac]

#25660: If an administrator triggers cron, a background update could temporarily
lock them out
-----------------------------+-----------------
 Reporter:  nacin            |      Owner:
     Type:  defect (bug)     |     Status:  new
 Priority:  high             |  Milestone:  3.7
Component:  Upgrade/Install  |    Version:
 Severity:  major            |   Keywords:
-----------------------------+-----------------
 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.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/25660>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software