- Issue created by @hfernandes
- Merge request !10998Issue #3502018 Installation fails if cron runs in parallel → (Closed) created by hfernandes
- 🇬🇧United Kingdom catch
#833094: Ajax requests in installer cause cron to run prematurely → fixed the same issue several years ago. The fix proposed here is very similar.
There should not be AJAX requests from the installer to the not-yet-installed site, wondering if somehow something in Drupal CMS is triggering this.
- 🇳🇿New Zealand quietone
Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .
- 🇵🇱Poland pjmuszynski
I was able to reproduce this issue, but sadly the fix doesn't work for me :(
Steps taken:
The steps to make sure that the issue is not present without the simultaneous cron run
- I initialized the Drupal 11 site.
- I installed the site via web UI by choosing the Standard installation profile.
- The process went without issues.
The steps with simultaneous cron run (during the install process)
- I initialized the Drupal 11 site.
- I installed the site via web UI by choosing the Standard installation profile.
- At the same time as the batch process continues I run the
drush cron
from the console. - The installation fails with the error: "The website encountered an unexpected error. Try again later." (more info in the screenshot attached).
- 🇬🇧United Kingdom catch
The cron run may be a red herring here - the overall issue is that any request to the site while the installer is running, can result in cache corruption.
- 🇧🇷Brazil hfernandes
@catch It’s possible.
@pjmuszynski Running the cron via the Drush CLI will consistently cause the installation to fail. While this doesn’t seem like a valid scenario—since it's unlikely someone would execute Drush commands during the Drupal installation—any Drush command (e.g.,
drush st
) will also trigger a failure. This happens because Drush bootstraps Drupal to execute commands, which might align with what @catch mentioned earlier. - 🇧🇷Brazil hfernandes
I believe I’ve identified the main issue here.
The
InstallerKernel::installationAttempted()
function relies on the$GLOBAL
variable to check if the installer is running. However, this only works within the same script execution. When Cron or Drush commands are executed, those requests don’t have access to the$GLOBAL
variables set by the installer.To resolve this, I propose updating
InstallerKernel::installationAttempted()
to also use Config Storage. During installation, a temporary config would be created and removed upon completion. This approach would allow us to verify the installation status across multiple requests. - 🇺🇸United States smustgrave
So the MR should still point to 11.x as it needs to land there first.
Also tagging for test coverge.
- Merge request !11097#3502018: Update the InstallerKernel::installationAttempted to use the config... → (Open) created by hfernandes
- 🇧🇷Brazil hfernandes
Fix target branch to 11.x and test coverage implementation.
- 🇺🇸United States smustgrave
Sorry Imeant there needs to be a test case added to show the bug. Not the test framework altered
- 🇧🇷Brazil hfernandes
@smustgrave I'm not sure if that's what you meant by "test case," but I attached two video recordings to this ticket demonstrating the issue.