[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                    |  Resolution:
 Keywords:  has-patch needs-testing  |
-------------------------------------+------------------

Comment (by azaozz):

 25660.3.diff merges 25660.2.diff and 25660.patch.

 > I think I would like to see heartbeat work once before treating a 503 as
 an error. That way we at least know there aren't persistent 503 errors
 spewing from admin-ajax.php.

 That's sensible. The only thing is that sites with only one user would
 take longer to trigger the error as we don't check post locks there, so
 heartbeat runs every couple of minutes instead of every 15 seconds (once
 an error is triggered heartbeat runs every 15 sec. until the error is
 cleared). And if maintenance mode lasts about 20 sec. chances are we will
 miss is.

 > ...we wanted to be certain in 3.6 that we weren't accidentally blocking
 someone from publishing just because their heartbeat or something is
 broken. 503 is specific enough, and meaningful enough, that we should be
 okay always treating a 503 as a connection issue.

 Was thinking about that too. When doing AJAX, most errors are some type of
 PHP notice/warning that prevents parsing the response (we currently bypass
 these). As @dd32 mentions above, responses with HTTP error 503 are quite
 specific and we should be preventing the user from saving while they
 persist. We could add a custom header when in maintenance mode but
 thinking all 503 should be treated the same.

 Also agree we can enhance that part of heartbeat and use it better. For
 (unrelated) example: when an error is detected, we could set a target on
 the form and keep the current Edit Post screen open while attempting to
 save the post. If it fails, the original content is still intact and the
 user can try again later.

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