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.

CommentFileSizeAuthor
uuri.patch2.24 KBchx
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett commented
Status: Needs review » Reviewed & tested by the community

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

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Status: Reviewed & tested by the community » Fixed

Seems reasonable.

Committed and pushed to 8.x. Thanks!

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Issue tags: +Configuration system

.

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler commented

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!

chx’s picture

chx CreditAttribution: chx commented

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...

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler commented

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!

chx’s picture

chx CreditAttribution: chx commented

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.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented

Just noting that #2069373: Race conditions on import if CUD on ConfigEntity A triggers changes in ConfigEntity B is related

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