Issue 5105: Process batches generated during drush config:import.

[sonfd]

A module may choose to initiate a batch process from hook_install(). The batch process is executed when a module is enabled in UI, via /admin/modules, or via config sync via /admin/config/development/configuration. Additionally, drush pm:enable mymodule also executes the batch process. Update the drush config:import command to use the same technique as drush pm:enable to get and process batches after every sync step.

[weitzman]

Its a little weird that config:import has to care about code in hook_install. What is the backtrace in the core /admin/config/development/configuration request when the batch gets processed?

[sonfd]

I'm not sure what the backtrace is. I'm not sure how to generate that for you.

But I'm assuming this has to do with how drush handles batch operations. You manually execute this same code during drush pm:enable (Drush\Drupal\Commands\pm\PmCommands::enable()), there's a commit specifically for this addition with message:

D9 Run batch process during pm-enable when needed. (#3446)

I would ask the same question about pm:enable - why would it need to care about the contents of a module's hook_install()?

[weitzman]

Because hook_install is about happens when enabling modules. config:import can result in enabling a module but thats more of a byproduct. Your patch may be right. My question is more about where to add the new code, and less about whether to add it.

FYI A backtrace can be viewed with by putting a call to print_r(debug_backtrace()) in the code where you want to get the info. It sometimes works to add a die() after that in order to actually see the printed info. Otherwise a debugger can stop and show you same info.

[sonfd]

Oh, of course, I see - that makes sense. Thanks for explaining! :)

I also wondered if this was the right place and/or whether it should be added to the core method that doImport says it's copying.

I've tried to get a backtrace in a couple different spots, but I am getting out of memory errors on the line with print_r(debug_backtrace()); (which is kind of wild because I have 1024M memory limit).

I set a breakpoint at the end of the Drupal\config\Form\ConfigSync::submitForm() and here is the stack from there, but this appears to be before the config is imported or my hook_install() batch has been processed.

ConfigSync.php:388, Drupal\config\Form\ConfigSync->submitForm()
FormSubmitter.php:114, call_user_func_array:{/var/www/html/web/core/lib/Drupal/Core/Form/FormSubmitter.php:114}()
FormSubmitter.php:114, Drupal\Core\Form\FormSubmitter->executeSubmitHandlers()
FormSubmitter.php:52, Drupal\Core\Form\FormSubmitter->doSubmitForm()
FormBuilder.php:592, Drupal\Core\Form\FormBuilder->processForm()
FormBuilder.php:320, Drupal\Core\Form\FormBuilder->buildForm()
FormController.php:73, Drupal\Core\Controller\FormController->getContentResult()
EarlyRenderingControllerWrapperSubscriber.php:123, call_user_func_array:{/var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php:123}()
EarlyRenderingControllerWrapperSubscriber.php:123, Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure:/var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php:121-124}()
Renderer.php:564, Drupal\Core\Render\Renderer->executeInRenderContext()
EarlyRenderingControllerWrapperSubscriber.php:124, Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext()
EarlyRenderingControllerWrapperSubscriber.php:97, Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure:/var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php:96-98}()
HttpKernel.php:158, Symfony\Component\HttpKernel\HttpKernel->handleRaw()
HttpKernel.php:80, Symfony\Component\HttpKernel\HttpKernel->handle()
Session.php:58, Drupal\Core\StackMiddleware\Session->handle()
KernelPreHandle.php:48, Drupal\Core\StackMiddleware\KernelPreHandle->handle()
PageCache.php:106, Drupal\page_cache\StackMiddleware\PageCache->pass()
PageCache.php:85, Drupal\page_cache\StackMiddleware\PageCache->handle()
ReverseProxyMiddleware.php:48, Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
NegotiationMiddleware.php:51, Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
StackedHttpKernel.php:23, Stack\StackedHttpKernel->handle()
DrupalKernel.php:708, Drupal\Core\DrupalKernel->handle()
index.php:19, {main}()

However, they set the config sync as a batch with batch_set() in that method.

This is the stack from the config import batch's finish callback (ConfigImporterBatch.php:54, Drupal\Core\Config\Importer\ConfigImporterBatch::finish()):

ConfigImporterBatch.php:54, Drupal\Core\Config\Importer\ConfigImporterBatch::finish()
batch.inc:456, _batch_finished()
batch.inc:98, _batch_page()
BatchController.php:55, Drupal\system\Controller\BatchController->batchPage()
EarlyRenderingControllerWrapperSubscriber.php:123, call_user_func_array:{/var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php:123}()
EarlyRenderingControllerWrapperSubscriber.php:123, Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure:/var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php:121-124}()
Renderer.php:564, Drupal\Core\Render\Renderer->executeInRenderContext()
EarlyRenderingControllerWrapperSubscriber.php:124, Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext()
EarlyRenderingControllerWrapperSubscriber.php:97, Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure:/var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php:96-98}()
HttpKernel.php:158, Symfony\Component\HttpKernel\HttpKernel->handleRaw()
HttpKernel.php:80, Symfony\Component\HttpKernel\HttpKernel->handle()
Session.php:58, Drupal\Core\StackMiddleware\Session->handle()
KernelPreHandle.php:48, Drupal\Core\StackMiddleware\KernelPreHandle->handle()
PageCache.php:106, Drupal\page_cache\StackMiddleware\PageCache->pass()
PageCache.php:85, Drupal\page_cache\StackMiddleware\PageCache->handle()
ReverseProxyMiddleware.php:48, Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
NegotiationMiddleware.php:51, Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
StackedHttpKernel.php:23, Stack\StackedHttpKernel->handle()
DrupalKernel.php:708, Drupal\Core\DrupalKernel->handle()
index.php:19, {main}()

I don't think these stack traces are useful, but maybe they're useful to you?

[weitzman]

I suspect that the form API is just processing any batches that were created by submit handlers. See \Drupal\Core\Form\FormSubmitter::doSubmitForm. So technically Drush needs to add the 3 lines you added here for any command that mimics a form. So, I'm leaning towards merging this PR but am thinking a bit more.