If config rollback fails validation, it's impossible to tell what caused the rollback in the first place

Can you share the recipe.yml file? The errors suggest that this it's using filter plugins provided by modules that are not yet installed. Which means the Recipe should declare a dependency on those modules.

If so, that suggests this is a missing piece of validation … and AFAICT #3423526: Validate that every config entity listed in the config.actions section of recipe.yml belongs to a module that was installed by the recipe, or one of its dependencies → already is the issue for adding that 😊

Yeah no problem I've just committed the code back into the main branch here which breaks the recipe apply with the error above https://github.com/millnut/localgov_recipe

Okay, now THAT is very interesting!

That's a pretty complex Recipe (many modules getting installed), but the modules providing those filters are definitely present. But … I cannot find where that text format is defined. In which module does that live?

AFAICT there are only two possible explanations here:

1. Incorrect install order: some config is being installed before some modules are installed.
2. Missing cache invalidation: the filter plugin manager is using a stale set of definitions — it's not being invalidated upon installing modules

Oh wait, I now see that it's saying it's trying to UNINSTALL the format. That makes no sense!

It implies two things:

• This format is already installed on your test site -> can you please do a config export of that and post it here?
• Since recipes cannot delete config, it must be some module that's uninstalling this text format upon installation … which of your recipe's modules is that?

Yep so the WYWIWYG text format gets installed by the localgov_media module under "config/optional", which is a submodule of the localgov_core module.

I tested this under a minimal profile so no existing WYSIWYG text format, I'll generate a full config export later today

Uploaded my `cex` export for the minimal site I'm testing against

Just the one file would've been enough 😅 But this'll work too. Can't look at it on this mobile device because of that though.

This is actually a more serious problem, I've found.

Normally, when the recipe application process throws an exception, we try to roll back to the previous state of config. If that fails, you get an exception like the one in the issue summary.

This is bad for two reasons:

1. Config isn't rolled back, so the broken recipe leaves a mess behind
2. The exception that caused the rollback is swallowed, effectively, and the root cause is not discoverable

This definitely needs to be fixed before the recipe system is ready for core.

I've come up with something simple but I think we should add test coverage... which will be fun.

Okay, wrote a test for this.

I think that pretty much covers it; we're not actually trying to fix the validation error itself, just the fact that the original exception is swallowed.

Re-titling for clarity of scope.

This looks great for a first past and at least does not result in hiding the error. I think we can improve the test and the code in a non core-mvp issue that @phenaproxima is creating right now.

Committed and pushed 2cf80c1e475 to 11.x and 17ef0c25e39 to 10.3.x. Thanks!

Cherry-picked to ✨ Add recipes api as experimental API to core Needs review

Follow-up is open: #3443539: Refactor RecipeCommandTest::testExceptionOnRollback() so that it doesn't rely on buggy core behavior → .

AFAICT the fix is incorrect/incomplete here? 😬 See #3443539-3: Refactor RecipeCommandTest::testExceptionOnRollback() so that it doesn't rely on buggy core behavior → .

Automatically closed - issue fixed for 2 weeks with no activity.