Problem/Motivation
ConfigInstaller loops over all optional config of all enabled modules and removes everything that has missing dependencies or does not depend on the module being installed.
It checks the config dependencies against both the already installed config and other optional configuration. That means it might have all dependencies for a certain config entity but those dependencies might themself not end up being installed because they are missing some of their dependencies.
So far, I've only been able to reproduce this with my kernel tests that install a large number of modules and then install configuration for lots of them.
What happens is this:
1. I have an entity view display for a node type that depends on the user module explicitly and I have that node type, both as optional config.
2. I'm installing lots of modules, including node, user and the module that provides this optional config.
3. Then I'm installing config, starting with user (No specific reason other than that user is a required module so that seems to make sense)
4. First it installs default config, then optional config of that module and then optional config of other modules that depend on user.
5. the $list of config to possibly create now includes my entity view display and the node type. It loops through that list and the entity view display config depends on that node type config, which is in the list and user, so we keep it.
6. The we get to that node type config, which could be installed but does not depend on user, so we don't.
The resulting list of optional config to install now contains the entity view display but not the node type. And trying to save that throws an exception.
I don't know if this is reproducible outside of kernel tests too. In my case, I was able to work around this by changing the order of modules to install config for (install node config first, then user).
Proposed resolution
Check dependencies in reverse dependency order, so that config objects are checked before those that depend on them.
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 2623940-7.patch | 5.19 KB | alexpott |
| #7 | 4-7-interdiff.txt | 4.52 KB | alexpott |
| #4 | 2623940-3.patch | 4.37 KB | alexpott |
| #4 | 2623940.3.test-only.patch | 2.47 KB | alexpott |
| #2 | config-installer-2623940-2.patch | 2.31 KB | berdir |
Comments
Comment #2
berdirHaven't tested it yet, but I think this change would be sufficient to solve my specific scenario.
There are other possible cases where config dependencies don't work, @alexpott is working on a patch that might fix some or all of those as well.
Posting this in case the other idea doesn't work out.
Comment #4
alexpottHere's a patch with a slightly different approach and a test
Comment #6
berdirDid you mean to write *in* the order... ?
Can we explain that unset with a comment somewhere?
the descriptions should say "are not met" in the assertNull lines here.
Additionally, it would be good to have a comment here that explains that the second case is an.. unexpected behavior, but is something that is not yet supported.
This issue can't also fix that, that's OK, we just fix the exceptions that can happen right now in this scenario.
Comment #7
alexpottThanks @Berdir - patch addresses the issues you've raised.
Comment #8
berdirForgot about this, I think this is still good to go.
Comment #12
catchCommitted/pushed to 8.2.x and cherry-picked to 8.1.x and 8.0.x. Thanks!