Roles can be deleted when upgrading from 9.5 to 10 if a module had removed permissions

I think the issue here is that a module is removing permissions while all this is happening, I think that needs to be done in a subsequent deploy

So I've tracked the code path that causes this issue, but still no idea how to fix it. What happens is the following:

1. user_update_10000 runs and removes the permission from the Role because it doesn't exist anymore
2. When the module is being uninstalled by config import we come to ConfigManager::getConfigEntitiesToChangeOnDependencyRemoval
3. This calls callOnDependencyRemoval which eventually ends up in Role::onDependencyRemoval
4. Since $this->permissions doesn't contain the permission (because it was removed in step 1) this function returns FALSE
5. That means back in getConfigEntitiesToChangeOnDependencyRemoval, $fixed is FALSE and therefore the role is added to $return['delete']

I think the issue here is that a module is removing permissions while all this is happening, I think that needs to be done in a subsequent deploy

In an ideal world, yeah. But I can imagine that there may be some modules out there that removed permissions in a D10 release. Maybe a site updates to that release in order to uninstall it during their D10 upgrade. That would result in the same bug.

For us, we were removing the block_content_revision_ui module. We use stub modules (i.e a custom module committed to the repo with just an info file) to allow us to uninstall the module at the same time as removing it from composer. This is a fairly edge case workflow but it could definitely happen with real module upgrades.

I'm experiencing something similar. We had the comment module installed (via the standard install profile in Drupal core) and removed it recently because of the security advisory related to that module. This caused some roles to be updated to remove permissions that were provided by that module. As a result, views which used role-based access control and referenced a role that was updated were deleted. We were able to import these views without modification using Configuration > Development > Config synchronization > Import.

This was happening to me too and in my situation there was a very easy workaround. I normally run "drush config-import" first before running "drush updatedb".

I just ran drush updatedb first so that permissions that would be removed when I updated the config wouldn't be removed yet.

@hyperlinked fwiw, you should always run updb before config import. Database updates can make changes to your configuration, those should be run on a local/development environment first and then the config changes should be exported. Then when deployed you'll have a clean deploy process with updb then import. This is how drush deploy works (highly recommend using that :))