>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3628616. --> Reported by: [sdaoudi](https://www.drupal.org/user/3097591) Related to !71 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>When a split removes a module (or complete-split config), <code>ConfigSplitManager::processEntitiesToChangeOnDependencyRemoval()</code> creates a <code>config_split.patch.*</code> for each config entity returned in <code>$changes['update']</code> by <code>ConfigManager::getConfigEntitiesToChangeOnDependencyRemoval()</code>. That code has two problems. Both lead to exports that are not stable, with noise in <code>config_split.patch.*</code> files. This is most visible with several stackable splits.</p> <h4>1. Patches are written for config that is not in the transforming storage</h4> <p><code>getConfigEntitiesToChangeOnDependencyRemoval()</code> works on the active configuration. Its result can therefore include config that is no longer in the transforming storage, for example config that an earlier split already removed during the same export, or that another <code>config.transform.export</code> subscriber filtered out.</p> <p>The <code>$storage-&gt;exists($name)</code> check is only done <em>after</em> <code>createPatch()</code>, and <code>createPatch()</code> already writes the patch to the split storage:</p> <pre><pre>$patch = $this-&gt;;createPatch($name, $original, $updated, $split);<br>if (!$patch-&gt;isEmpty() &amp;&amp; $storage-&gt;exists($name)) {<br>&nbsp; // ...<br>}</pre></pre><p>The split then ends up with an orphan <code>config_split.patch.X</code> that does not match any config in the export. <code>mergeSplit()</code> already skips patches for config that does not exist in the storage ("Skip patches for config that doesn't exist in the storage."), which suggests the export side should not create them in the first place.</p> <h4>2. The patch baseline does not match the updated value</h4> <p>The two sides of the diff come from different sources:</p> <ul> <li><code>$original = $this-&gt;;active-&gt;read($name)</code>: raw data from the active storage.</li> <li><code>$updated = $entity-&gt;toArray()</code>: a loaded entity that was then modified by <code>onDependencyRemoval()</code>.</li> </ul> <p>For some entity types, the loaded entity holds runtime values that are not in storage. For example, <code>EntityDisplayBase::init()</code> fills in default options for extra fields and for fields that are not listed in <code>content</code>/<code>hidden</code>, and adds them to <code>content</code> or <code>hidden</code>. These values show up in the diff as "added", although they have nothing to do with the dependency removal.</p> <p>Example with <code>core.entity_view_display.user.user.default</code> when splitting <code>domain_access</code>:</p> <pre><pre># Active storage (baseline today)<br>hidden:<br>&nbsp; field_domain_access: true<br>&nbsp; field_domain_admin: true<br>&nbsp; field_domain_all_affiliates: true<br><br># Entity after onDependencyRemoval() (init() added extranet_data_profiles)<br>hidden:<br>&nbsp; extranet_data_profiles: true</pre></pre><p>The resulting patch removes the three domain fields, which is expected. It also adds <code>hidden.extranet_data_profiles</code>, which is unrelated. That entry is then merged into the exported sync file and inverted again on import.</p> <h3 id="summary-steps-reproduce">Steps to reproduce</h3> <p><strong>Case 1</strong></p> <ol> <li>Create two stackable splits, A and B, with A running before B on export.</li> <li>A completely splits a config entity X, for example <code>core.entity_view_display.node.foo.default</code>.</li> <li>B splits a module M, such that removing M updates X instead of deleting it (for example, a field provided by M is shown on that display).</li> <li>Run <code>drush cex</code>.</li> <li>Result: B contains <code>config_split.patch.core.entity_view_display.node.foo.default</code> although X is not in the sync export.</li> </ol> <p><strong>Case 2</strong></p> <ol> <li>Split a module that provides fields shown on an entity display, where the bundle also has an extra field or a field with default display options that is not stored in the display config.</li> <li>Run <code>drush cex</code>.</li> <li>Result: the display's patch contains entries for components that have nothing to do with the split module.</li> </ol> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <ol> <li>Skip the entity before calling <code>createPatch()</code> if the config does not exist in the transforming storage.</li> <li>Build the baseline from the same representation as the updated value: load the entity before the removal with <code>ConfigManagerInterface::loadConfigEntityByName()</code> and use <code>toArray()</code>. <code>getConfigEntitiesToChangeOnDependencyRemoval()</code> works on cloned entities, so the loaded entity still holds the pre-removal state. Both sides of the diff are then normalized the same way, and the patch only contains the changes caused by the dependency removal.</li> </ol> <pre><pre>foreach ($changes['update'] as $entity) {<br>&nbsp; $name = $entity-&gt;getConfigDependencyName();<br>&nbsp; if ($split-&gt;exists($name)) {<br>&nbsp;&nbsp;&nbsp; continue;<br>&nbsp; }<br>&nbsp; if (!$storage-&gt;exists($name)) {<br>&nbsp;&nbsp;&nbsp; continue;<br>&nbsp; }<br><br>&nbsp; $originalEntity = $this-&gt;manager-&gt;loadConfigEntityByName($name);<br>&nbsp; if (!$originalEntity) {<br>&nbsp;&nbsp;&nbsp; continue;<br>&nbsp; }<br>&nbsp; $original = $originalEntity-&gt;toArray();<br>&nbsp; $updated = $entity-&gt;toArray();<br><br>&nbsp; $patch = $this-&gt;createPatch($name, $original, $updated, $split);<br>&nbsp; if (!$patch-&gt;isEmpty()) {<br>&nbsp;&nbsp;&nbsp; $data = $storage-&gt;read($name);<br>&nbsp;&nbsp;&nbsp; $data = $this-&gt;patchMerge-&gt;mergePatch($data, $patch, $name);<br>&nbsp;&nbsp;&nbsp; $storage-&gt;write($name, $data);<br>&nbsp; }<br>}</pre></pre><p>The attached patch includes unit tests for both cases (<code>ConfigSplitManagerDependencyPatchTest</code>).</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Review the approach, especially whether the baseline should come from <code>$source</code> in stackable mode instead.</li> <li>Possibly turn the unit tests into kernel test cases in <code>SplitContentEntityTypeTest</code>.</li> </ul> <h3 id="summary-ui-changes">User interface changes</h3> <p>None.</p> <h3 id="summary-api-changes">API changes</h3> <p>None.</p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>None. Exports may lose orphan or noisy <code>config_split.patch.*</code> files.</p> <h3>Related issues</h3> <ul> <li>#3239366: Config Patches creation needs to consider existing patches</li> <li>#3514034: Do not completely split items depending on patched ones</li> </ul> >>> [!note] Pre-migration files - [config-split-dependency-update-storage-guard.patch](https://www.drupal.org/files/issues/2026-10-05/config-split-dependency-update-storage-guard.patch) >>>