### Release notes Faster and more reliable SCIM member removal for groups SCIM `DELETE` and `PATCH` requests to deprovision group members now complete immediately, with the actual membership removal handled asynchronously in the background. This eliminates request timeouts that previously caused 500 errors for organizations managing large numbers of users through SCIM. Identity providers and SCIM clients will now receive a reliable success response, making automated user lifecycle management significantly more robust. ### Problem Follow-up to https://gitlab.com/gitlab-org/gitlab/-/issues/506829+. The SCIM user deprovisioning endpoint under `PATCH /api/scim/:version/groups/:group/Users/:id` triggers a large number of database queries when removing a user with large number of memberships. These memberships are removed one by one via `Members::DestroyService` calls leading to N+1s. User deprovisining should be asynchronous. The [SCIM RFC](https://datatracker.ietf.org/doc/html/rfc7644#page-32) requires us to return `200` status code, so we need to: 1. make the user identity inactive and block the user synchronously 2. make membership removal asynchornous using [`Members::ScheduleDeletionService`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/members/schedule_deletion_service.rb#L4). ### Proposed solution We need to handle the scenario where a user is deprovisioned, then quickly reprovisioned. - With the current synchronous processing, this is not an issue, and as all membership are removed during the first API call - However, with making the deprovisioning partially asynchronous, we need to we need to block reprovisioning until the membership removal is fully completed to prevent inconsistencies.