Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.How to reproduce:
- install config_distro module (I tried it with confic_sync suite)
- do some edits on configuration items in a custom module's /config/install folder
- run drush config-distro-update
Expected: the changes would be detected and offered to update
Actual: no changes to import
A workaround to fix is to rebuild caches using "drush cr" command before. Then, running "drush config-distro-update" again detects the change correctly.
Also, running the same from UI (/admin/config/development/configuration/distro) works properly. So I would guess there is some cache invalidation problem in drush version only.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 3007269-changes-clear-cache-12.patch | 6.05 KB | a.dmitriiev |
| #5 | 3007269-changes-clear-cache-5.patch | 2.88 KB | a.dmitriiev |
Issue fork config_distro-3007269
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:
changes
Comments
Comment #2
nedjoConfig Distro doesn't itself add any updates but only provides the means for other modules to do so. Therefore moving this bug to Configuration Synchronizer.
Comment #3
a.dmitriiev commentedMaybe drush command misses the change https://git.drupalcode.org/project/config_sync/-/commit/1bed6aeae98c1ac7... that was added to ConfigSyncForm for clearing the filters cache?
So if the same change is added to config distro (cd-update command) it will show the changes during the run without clearing the caches (drush cr) before?
Comment #4
a.dmitriiev commentedComment #5
a.dmitriiev commentedMoving back to config distro with patch that fixes the problem.
Comment #6
a.dmitriiev commentedComment #7
nedjoThanks for tracking this bug down. The fix indeed looks correct.
But we're about to remove the
config_filterdependency in #3080778: New API for config_distro modelled after the new CMI2 config transformation API . We could consider moving this to theconfig_distro_filtersubmodule proposed in that issue, but my feeling is it's best to expect modules still usingconfig_filterto take responsibility. In theconfig_synccase, this would mean altering the Drush command provided byconfig_distro. As it happens, that's something we should be doing anyway, per #2997360: Add Drush command for the "reset" update mode. So I think this belongs back inconfig_syncvia a Drush command alter.Comment #8
nedjoMoving to Configuration Syncrhonizer per #7.
Comment #9
a.dmitriiev commentedMaybe it is better to use Event dispatch approach here? Config Distro dispatches now the event on successful import, let's add one more event before import, and in config sync event subscriber will clean the config filter caches? This way we will not mess up with dependencies?
Comment #10
nedjo@a.dmitriiev agreed, that sounds like a solid approach.
Comment #11
a.dmitriiev commentedComment #12
a.dmitriiev commentedI move the issue back to config distro, because it belongs here, as config_distro_filter module can also react on the new event.
I will create a follow up issue in config_sync module to react on PRE_IMPORT event, in case config_distro_filter module is not enabled (for the future cases when config_filter module will not be used anymore).
Comment #15
trackleft2Comment #16
trackleft2I've updated the issue to add a merge request that attempts to update the patch with the 2.x version of config_distro in case this helps anyone.
I've also fixed some code style issues.
Comment #17
trackleft2