Problem/Motivation

After the changes in #3532693 (released as 3.0.0-alpha3), drush site-install with a custom installation profile fails with PreExistingConfigException for any module that has config/install/ files overlapping with its dependencies' config. This is affecting custom modules shipped by Features.

Steps to reproduce

  1. Create a custom installation profile that includes a Features-generated module (e.g., my_analytics) which depends on google_tag and ships config/install/google_tag.settings.yml
  2. Run drush site-install my_profile

With alpha2: Installation completes successfully. With alpha3: Fails with:

Configuration objects (google_tag.settings) provided by my_analytics already exist in active configuration

I found that this affected all Features-generated modules. Removing the first failing module just causes the next module in the profile to fail with the same error.

What I found

I added debug logging to ConfigProviderConfigInstaller and discovered that setSyncing() is never called on the decorator during profile module installation. Every call to checkConfigurationToInstall() runs with isSyncing() returning FALSE:

checkConfigurationToInstall(module, [batch 1 of ~20 modules]) - isSyncing: FALSE
checkConfigurationToInstall(module, [batch 2 of ~20 modules]) - isSyncing: FALSE
checkConfigurationToInstall(module, [batch 3 of ~20 modules]) - isSyncing: FALSE

The setSyncing() override produced zero log entries — it was never called at all.

The workaround is to revert to alpha2, but that breaks Drupal 11.2+ compatibility and a cascade of other dependencies in order to get site-install to function, so a fix is needed.

Environment

  • Drupal core 11.3.3
  • config_provider 3.0.0-alpha3
  • config_sync 3.0.0-alpha5
  • Features 3.16.0
  • Drush 13.7.1
  • PHP 8.3

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

CommentFileSizeAuthor
#9 config_provider-delegate-config-check-3572966-9.patch2.61 KBtadean
#2 skip-check-during-install.patch1.14 KBmprell

Issue fork config_provider-3572966

Command icon 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:

About issue forks

Comments

mprell created an issue. See original summary.

mprell’s picture

mprell commented
StatusFileSize
new skip-check-during-install.patch1.14 KB

I've tested a working fix for this. The approach overrides checkConfigurationToInstall() in ConfigProviderConfigInstaller to skip the pre-existing configuration check during site installation:

use Drupal\Core\Installer\InstallerKernel;

public function checkConfigurationToInstall($type, $name) {
  if (InstallerKernel::installationAttempted()) {
    return;
  }
  parent::checkConfigurationToInstall($type, $name);
}

checkConfigurationToInstall() runs before getConfigToCreate(), so the exception fires before config_provider can handle the overlap. Skipping the check during installation (when InstallerKernel::installationAttempted() is TRUE) lets the existing config provider logic do its job. Post-install module enablement still runs the normal validation.

Applied as a composer patch against alpha3. Full drush site-install with a 60+ module profile completes successfully, including install_profile_modules. Attaching the patch.

joegraduate made their first commit to this issue’s fork.

joegraduate opened merge request !23

joegraduate’s picture

joegraduate
Primary language English
Location Arizona, USA
commented
Status: Active » Needs review

Thanks for the detailed issue report(s) @mprell! Created a MR from your patch in #2. I'm going to try to do some testing with this and I'll reach out to @tadean to review/test as well.

joegraduate’s picture

joegraduate
Primary language English
Location Arizona, USA
commented

Addressed (existing) PHPCS errors in separate isssue: #3574726: PHPCS errors (SlevomatCodingStandard.Commenting.ForbiddenComments.CommentForbidden)

joegraduate changed the visibility of the branch 3.0.x to hidden.

tadean’s picture

tadean
Primary language English
Location Arizona, USA
commented

@mprell @joegraduate I went back through the different MR approaches that were tried in #3532693: Update config_provider to be compatible with ConfigInstallerInterface changes in Drupal >=11.2 and #3532693-12: Update config_provider to be compatible with ConfigInstallerInterface changes in Drupal >=11.2 testing them with the same setup that @mprell described, with some hope that maybe one of the other approaches were were considering would not exhibit the issue, but unfortunately they all have the same problem that @mprell mentioned.

I'm doing some testing with !23. Thanks @mprell for your work on this!

tadean’s picture

tadean
Primary language English
Location Arizona, USA
commented
StatusFileSize
new config_provider-delegate-config-check-3572966-9.patch2.61 KB

I did some testing on this alongside features, and it seems like it doesn't work identically to features in all cases. Features appears like it might allow installation of features modules that share configuration even if it's not site install time.

In !23, it works at site install, but not at other times.

Would a potential approach be to save the decorated service and allow it to weigh in on the configuration check? I've attached a potential patch. Not sure what risks this decorated service approach might have. (Patch is versus 3.x).

In the case of features, if features is the decorated installer, it runs its own overridden findPreExistingConfiguration() inside checkConfigurationToInstall() which allows for features modules to skip the check, and the Drupal core implementation still blocks the duplicate configuration if features isn't enabled.

joegraduate’s picture

joegraduate
Primary language English
Location Arizona, USA
commented

The approach you took in your new patch seems reasonable to me, @tadean.

joegraduate’s picture

joegraduate
Primary language English
Location Arizona, USA
commented

@mprell Any chance you might be able to test @tadean's patch in #9 to see if it resolves the issue you've been seeing?