Running the de-provisioning script in Go keeps failing at the /scim/v2/groups/{groupId} endpoint. The atomic DELETE operation with http.MethodDelete returns a 409 Conflict when the payload includes the cascade: true directive alongside the member removal matrix. I’ve structured the request body as {"members": [{"value": "usr_8821", "op": "remove"}], "cascade": true, "audit_ref": "dep_run_04"} but the identity gateway rejects it. The error response shows "error": "max_member_count_exceeded", "message": "Dependency check failed for orphan prevention pipeline." which doesn’t make sense since the group only has three active bindings.
I tried adding a pre-flight validation step using GET /scim/v2/Groups?filter=displayName eq "legacy_queue_admins" to verify the schema constraints against identity gateway limits, but the response payload still lacks the maxMembers field. The cleanup triggers aren’t firing automatically after the client.Do(req) attempt. I need the atomic operation to clear all membership references before the group object gets purged, otherwise the external directory sync webhook at https://hooks.internal/scim/deprovisioned receives stale user tokens during identity scaling.
The latency tracking shows the request hangs around 4.2 seconds before the 409 drops. I’ve added req.Header.Set("Content-Type", "application/scim+json") and verified the OAuth bearer token via client.SetBearerToken(). The dependency checking logic in the verification pipeline seems to block the cascade directive entirely. How do I format the de-provisioning payload to bypass the orphan prevention constraint while keeping the audit logs intact? The transaction keeps rolling back and leaving access residue on the routing queues.