Problem/Motivation
This issue was found during BDD testing.
When deleting a user, and there are OpenStack cloud service providers assigned to that UID, the following update code runs during the deletion process.
function openstack_cloud_config_update(CloudConfig $cloud_config): void {
if ($cloud_config->bundle() === 'openstack') {
openstack_update_resources($cloud_config);
}
}
In doing so, it will try to update all openstack instances. This causes the system to hang, and never return. Ultimately, it hogs up all DB resources.
The problem arises because Drupal's user delete runs in batch mode, utilizing the progress bar, known as Progressive batch. If openstack_update_resources($cloud_config); runs, it will try to run another batch process to update resources. That batch runs in non-progressive mode.
Doing so confuses the original batch processing. (We have both progressive and non-progressive batch processing happening) Drupal will pick up CloudService::batchProcessEntities() indefinitely, and never return.
tl;dr: You can't run a progressive batch and within that batch try to run a non-progressive batch. It confuses Drupal and causes it to loop and never return.
Issue fork cloud-3315797
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
baldwinlouie commented@yas Here is the patch to fix this issue. The fix is to skip updating openstack resources if coming from anything other than the cloud_config edit page. This is how the
K8smodule is setup.Comment #3
yas@baldwinlouie
Thank you for identifying and fixing the issue. I tested the patch by running the BDD testings several times, it worked fine. I'll merge the patch to
4.xand5.x, and close this issue as Fixed.Comment #6
yas