Rebuild script triggers errors in error handler, fails to rebuild container

Without that condition, the rebuild script shows a PHP notice (native PHP error handler) and depending on display_errors in php.ini, it does not redirect.

I guess that could be considered minor.

However, in case the rebuild happens to fail due to other errors/exceptions later on in dfac(), then I'm back to the same error when going back to the actual site:

Fatal error: Call to a member function get() on a non-object in core\lib\Drupal.php on line 157
{main}( )
drupal_handle_request( )
Drupal\Core\DrupalKernel->boot( )
Drupal\Core\DrupalKernel->initializeContainer( )
Drupal\Core\DrupalKernel->buildContainer( )
Drupal\Core\DrupalKernel->initializeServiceProviders( )
Drupal\Core\DrupalKernel->discoverServiceProviders( )
_drupal_error_handler( )
_drupal_error_handler_real( )
_drupal_log_error( )
watchdog( )
Drupal::request( )

Putting back the isset() adjustment in DrupalKernel, Drupal at least boots on regular pages again.

So I think we should leave it in and commit the patch as-is.

The ultimate goal of the rebuild script is to recover to a functional container/DrupalKernel state. Whenever you have to manually rebuild, something went terribly wrong and there's a 99% chance that the system contains stale data either way.

I think so, yes.

After further debugging investigations, I now agree that the change to DrupalKernel should not be contained in here, as the container is continuously rebuilt on every request without any kind of notice or warning that something is wrong.

I'll create a separate issue for that problem.

With that debatable change out of the way, I hope we can move forward here now.

Created #2161995: Faulty module cannot be removed from module list; DrupalKernel rebuilds container on every page request

I'm not able to see the point of trying to get a custom error handler to work in a scenario in which the entire application is known to not be operable?

The custom error handler tries to (1) log using watchdog(), (2) dsm() an error message, (3) initialize the [maintenance] theme, etc.

We can certainly hack the error handler code with further conditionals, but the end result is going to be the same in the concrete case of drupal_rebuild(): The custom error handler is not functional, an error must be displayed and/or logged, so you are able to identify the problem and recover.

Perhaps you can explain what kind of benefit the custom error handler would have (because I fail to see one), and why we want to use it in a scenario in which it and all of the services it attempts to use cannot work?

All other situations are setting up a special environment and custom container/DrupalKernel, because they already know that services are not available yet. The way that is done is still a big sad mess and should be improved, but that is OT for this issue.

But drupal_rebuild() operates at the opposite end: The only thing it knows is that the application that previously was operable is no longer operable. To which extent, is unknown. It is not able to predict whether the rebuild will succeed or whether it will throw any notices, warnings, errors, or exceptions and break in the middle.

Lastly, drupal_rebuild() does not render an HTML page, but the custom error handler is designed to collect, aggregate, and render errors in a full page output. In turn, we'd only add more spaghetti to the custom error handler and we'd have to add a fragile way to retrieve and render errors in the output of a script that isn't supposed to render a page-alike thing to begin with.

The scope of this issue is limited to the rebuild script. PHP's native error handling does exactly what it is supposed to do and fully matches developer expectations within this limited scope. It is unnecessary to overload it with a custom and fragile behavior.