The config sync process shouldn't change the configuration at all if the validation fails for any reason, at any point.

I attempted an import that included installing (enabling) a new custom module. It failed because of a new module dependency. However, the status of that new custom module was changed to "installed". And since the import didn't complete, it was difficult to tell which items were and were not done.

Comments

ExTexan created an issue. See original summary.

Version: 8.3.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Branches prior to 8.8.x are not supported, and Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented
Related issues: +#1842956: [Meta] Implement event listeners to validate imports

This one is interesting. What does

It failed because of a new module dependency.

actually mean? We check that all the modules in core.extension exist prior to install. I'm guessing that maybe the new module has a dependency that is not in core.extentsion?

But also this suggests that either code change has occurred or the core has been edited externally. In which case #2628144: Ensure that ConfigImport is taking place against the same code base and #2762235: Ensure that ConfigImport is taking place without outstanding updates are relevant.

extexan’s picture

extexan commented

@alexpott, Unfortunately, I can't recall exactly what caused the sync to fail, as it is now more than 2.5 years since the issue was created. But I think it was something that changed in Drupal that "created" a new dependency of some sort.

The sequence of events would have been something like this:

  • Site was running under Drupal 8.x
  • Developer A created a new custom module and was able to install it because the dependency (in core) didn't exist.
  • Developer A finishes work on custom module and exports the config (with the module installed).
  • Site gets updated to Drupal 8.y
  • Developer B (me) tries to update the site with the branch containing the new module created by Developer A.
  • The dependency (now in Drupal core) stops the sync, not in the initial "audit" mode, but after it has already processed other config sync items, including setting the new module to "installed" status.

I realize it would be pretty much impossible to track down the original cause of the above issue, but really the point of this post was to ensure that nothing is changed in the config before checking that there are no roadblocks that would keep it from completing.

With that said, though, I think the config sync already has that sort of checking process in place, but the issue described above missed getting added to the initial audit process, but was already present in the code that actually enables modules. So, looking at it in that light, I would say it was just an issue back then, but probably no longer exists at this late date.

Feel free to close this issue as outdated.

cilefen’s picture

cilefen commented
Status: Active » Closed (outdated)