Group permission checking peformance issue after updates

was called 18 times on a page refresh of /node/add/blog before the update and now after the update it is called 7058 times

Holy crap

Any idea what could be causing such an extreme difference?
Could this be a caching issue or issue with the permission calculator?

Not unless this can be reproduced on a clean install. I have no clue what custom code and/or patches you have running, so either please run xhprof, Blackfire or whatever performance testing tool you're confident using or see if you can reproduce this on a clean install.

Erring on the side of Major right now as if this is the case for all Group installs, something is really broken.

Thank you, I understand. There is a lot of custom code so I would say this is site specifi9c issue, and I have checked on a similar site but was not able to reproduce it there. I will roll back the group update and see if there is any change.

Profiling shows that the access checking is running on menu items (structured in a large menu) which is loading on the create node pages and group entity access is called in that call stack, so I am trying to understand if these group entity access checks were cached before and at which layer they were cached.

Okay, please keep me posted.

I found that the changes from https://www.drupal.org/project/drupal/issues/2463753 🐛 [regression] Do not bypass route access with 'link to any page' permissions for menu links Fixed causes the performance issue.

I can see that when menuLinkCheckAccess is called it is not returning `$access_result->cachePerPermissions();` any more so the cacheContexts and cacheTags has changed from:

Drupal\Core\Access\AccessResultAllowed 
  #cacheContexts: array:1 [▼
    0 => "user.permissions"
  ]
  #cacheTags: []
  #cacheMaxAge: -1
}

to this:

 Drupal\Core\Access\AccessResultAllowed {
  #cacheContexts: array:3 [▼
    0 => "url.query_args:auHash"
    1 => "user.permissions"
    2 => "languages:language_interface"
  ]
  #cacheTags: array:25 [▼
    0 => "group_content_list:plugin:group_node:blog"
    1 => "group_content_list:plugin:group_node:<content_type_2>"
    3 => "group_content_list:plugin:group_node:<content_type_3>"
    ...
  ]

There are 23 cacheTag items coming from `group_content_list:plugin:group_node:.

Not sure if that is expected but seems to cause in issue in my case.

I've opened 🐛 Node menu form element checks access for every link for admin users Active against core for what I think is the performance regression on the node edit form relative to 10.2.x due to 🐛 [regression] Do not bypass route access with 'link to any page' permissions for menu links Fixed .

The group_relationship list cache tags look unnecessary per 📌 Try to remove group_relationship list cache tags in group_entity_access() Active . While the core issue would stop the access check running at all on node edit forms, the access checks will still need to run for actual menu block rendering and those cache tags can cause cache invalidation issues there, the new groups issue should resolve that.