Enabling SCIM returns a 500 for non-Okta SSO providers after a disable/re-enable

Environment

SaaS (https://sentry.io/)

Steps to Reproduce

1. Set up a non-Okta SSO provider (e.g. Active Directory / SAML2) on an org.
2. Settings → Auth → enable SCIM, Save.
3. Disable SCIM, Save. (SCIM turns off immediately, but the underlying SCIM install is only cleaned up asynchronously.)
4. Re-enable SCIM and Save before that cleanup completes.

Expected Result

Re-enabling SCIM works (or is safely handled), no server error.

Actual Result

HTTP 500. The server hits IntegrityError: duplicate key value violates unique constraint "sentry_sentryappinstalla_provider_organization_id_1bf014b7_uniq" in enable_scim (src/sentry/models/authprovider.py). The leftover-install check appears to look specifically for an okta_scim record, so for non-Okta providers it doesn't catch the org's existing _scim record and the re-create collides on the unique constraint. Okta orgs aren't affected.

Appears long-standing, not a recent regression.
See the linear case for more info.

Leaving the exact fix to the owning team.

Product Area

Settings - Auth

Link

No response

DSN

No response

Version

No response

Start in src/sentry/models/authprovider.py at enable_scim and trace the leftover-install check alongside the asynchronous cleanup after disabling SCIM. Verify the behavior for a non-Okta SSO provider such as Active Directory or SAML2. Done means disabling and quickly re-enabling SCIM no longer produces the duplicate-key HTTP 500.