[wp-trac] [WordPress Trac] #62176: No stable error detection after Automatic Updates with more than one update

[WordPress Trac]

#62176: No stable error detection after Automatic Updates with more than one update
-----------------------------------+------------------------------
 Reporter:  georgwordpress         |       Owner:  (none)
     Type:  defect (bug)           |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  Upgrade/Install        |     Version:  6.6
 Severity:  normal                 |  Resolution:
 Keywords:  2nd-opinion has-patch  |     Focuses:
-----------------------------------+------------------------------

Comment (by georgwordpress):

 @costdev
 > "thousands of tests prior to the feature's release"

 \\
 @afragen
 I can understand that nobody wants to make major changes to the existing
 code without good reason. After all, it was a very long way until part 3
 went live.

 Testing autoupdates/rollback can be terribly time-consuming and
 frustrating.

 Hence my initial question in this ticket to the developer:
 Is the result of my code review and therefore a need for action
 understandable?

 Maybe my PR is too big a leap?

 Then maybe a smaller step:
 We need at least log entries when the current function does not work as
 expected.

 In some places it simply reports back that no error was found, even though
 the real error check did not take place.

 For example, right at the beginning there are some bailouts with return
 false ==> no error founds.
 Here I would at least expect a warning in the error log that the error
 detection cannot be carried out as expected.

 The current code:
 {{{
     protected function has_fatal_error() {
         global $upgrading;

         $maintenance_file = ABSPATH . '.maintenance';
         if ( ! file_exists( $maintenance_file ) ) {
             return false;
         }

         require $maintenance_file;
         if ( ! is_int( $upgrading ) ) {
             return false;
         }
         ....

 }}}

 My suggestion therefore:
 1.) We don't change anything in the current processes.
 2.) But we only introduce a few additional log entries in the function
 {{{has_fatal_error}}} if something does not work as intended in the
 concept when checking for errors.


 @afragen, @costdev
 Do you support this approach?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62176#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform