The config dependencies of the Index entity doesn't have a consistent order. Each dependency should be added using \Drupal\Core\Entity\DependencyTrait::addDependency() ensuring that it's sorted if it doesn't already exist in the list.
Inspect the exported config of a search api index with multiple config/module dependencies.
Ensure the dependencies are sorted.
Provide issue fork/patch.
An update hook might be required to resave existing search index.
Show commandsStart 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 #3
codebymikey commentedComment #5
drunken monkeyThanks a lot for reporting this and already providing an MR. Looks pretty solid.
However, I don’t think it’s necessary to fix the dependency order right away, since the dependencies are basically fine. As far as I can see, the current unreliable ordering just means that there might be nonexistent changes reported for exported configs. Doesn’t seem worth it to report a nonexistent change in order to fix that. Seems to me like it would be fine to just have this fixed and reliable starting from the next time the user actually modifies the search index.
In case you disagree, please explain how fixing the order right away would or could be beneficial for users.
Comment #6
codebymikey commentedI just thought it made more sense to follow the common convention of having the configuration updated as part of the module update as necessary just like core did with the
system_post_update_sort_all_config()hook #2852557: Config export key order is not predictable, use config schema to order keys for maps, since that's one of the main reasons the ConfigEntityUpdater exists.This ensures the config changes are a lot more predictable and consistent if it's done once as part of the module update, so subsequent config exports will only include things the user actually changed in the index.
I think a change in the dependency order is an existent change (just like a change in config key orders according to the schema would be).
The update hook was useful for my use case because one of my distributions has multiple search index entities included and their dependencies needed to be automatically reordered in order to match what they should be on a clean install, otherwise they'd show up in my config diffs as a missing distribution change.
Either way, I don't have that strong a stance on it either way if you feel it's detrimental to the DX, and can reapply the post update hook myself, but I personally find it easier if such config changes are automatically documented for the developer via the update hook, so they're aware and can choose what to do with it after the database update (keep, or ignore it)
Comment #7
codebymikey commentedCalling
ConfigEntityUpdateron an Index entity currently leads to settings such as "processor_settings" being reordered by weight rather than alphabetically as per the schema.This is because
ConfigEntityUpdaterflags the entity has havingtrustedData(), meaning that it should no longer do any side effects such as removing/adding processors, but this wasn't taken into account in the entity.I added the explicit sorts as a fallback in case it's decided that the module should still attempt those kind of configuration changes even with trusted data.
Comment #8
drunken monkeyMakes sense, agreed. I just fixed one comment and then merged.
Thanks again!