As we found in #2106171: Write tests for simple configuration deployment scenario , importing the same config for the second time breaks as the user role action configuration entities will be recreated with different UUIDs. We have no test here, the parent contains the test.

Files: 
CommentFileSizeAuthor
uuri.patch2.24 KBchx
PASSED: [[SimpleTest]]: [MySQL] 58,912 pass(es).
[ View ]

Comments

Status:Needs review» Reviewed & tested by the community

Despite the large looking patch, this just adds !entity_load() checks, and indents a bunch :)

Status:Reviewed & tested by the community» Fixed

Seems reasonable.

Committed and pushed to 8.x. Thanks!

Issue tags:+Configuration system

.

Maybe this is a stupid question, but can someone explain why this happens with a little bit more detail? I checked and user_user_role_delete() deletes the actions properly, that were created in user_user_role_insert(). So it seems hook_user_role_insert() is being fired on roles that are already in the system during config import?! That seems very strange. I'm not so much worried about these two if-checks, but it seems if this is something that happens for all config entities, it could totally trip up a bunch of contrib and custom modules out there. In general I would expect the hook_*_insert(), hook_*_delete() combo (with hook_*_update() optionally) to do the trick.

Thanks!

When you import a new role , the action gets created and then the action tries to be imported and sync gives up because action already exists with a different UUID...

Ahh, that totally makes sense, thanks!

So this hits anyone with a "if config entity A is created, create config entity B" business logic, I guess. Don't really know what to do about that, though. I don't know we could write some sort of meta-generic cmi import tests... Hmm...

Anyway, thanks for the explanation!

Note: I was slightly wrong order (but not effect) wise, the action entity gets imported first, then the role gets imported which tries to re-save a completely new action entity with the same id.

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