The problem is here

                # Add a custom role                
if use_mapping_from_db:                    
   binding_mapping = BindingMapping.objects.get(role_id=db_role_id)                    
   if binding_mapping is None:                        
      raise Exception("V2 role bindings not found in db")
                    v2_uuid = binding_mapping.find_v2_role_by_permission(permissions)                
   else:                    
     v2_uuid = uuid.uuid4()

In the branch from RHCLOUD-35016 the problem is still there just expressed slightly differently:

                # Add a custom role                
if binding_mapping:                    
   v2_uuid = binding_mapping.find_v2_role_by_permission(permissions)                
else:                    
   v2_uuid = uuid.uuid4() 

Both share this:

def find_v2_role_by_permission(self, permissions):        
   """Find v2 role by permissions."""        
   v2_uuid = None        
   for v1_role_uuid, data in self.mappings.items():            
      if set(data["permissions"]) == set(permissions):                
         v2_uuid = data["v2_role_uuid"]
    if v2_uuid is None:            
        raise Exception(f"v2_uuid not found in mappings for v1 role {self.role.uuid}")        
   return v2_uuid 

The problem there is that the operation fails if there is no existing role mapped with that set of permissions. So when you change the set of permissions, it fails.

What do we want to happen?

This is an interesting migration question.

We are starting from a custom v1 role. This may result in needing zero or more custom roles in the v2 model. It depends on the unique sets of permissions per v2 resource (e.g. workspace). In the case custom roles are needed, we can potentially reuse the same custom role for different resources, even across different v1 custom roles, but this complicates migration.

A reasonable starting point is probably that for each resource referred to by a v1 custom role, we get a unique v2 custom role if one is needed. Then, if the permissions change for that v1 role and resource, we just update the v2 custom role. This avoids churn in the data and is reasonably easy to compute.

So, rather than lookup existing v2 roles by permission, we should probably lookup by resource. Then we can safely modify those roles since we know it only applies to those resources within the scope of one v1 role.