Revert "fix(modal): Contain render errors within the dialog" - #129728

Reverts #129199 (cc @TkDodo for context).

What breaks

Since #129199 shipped, a Sentry employee who opens a customer-domain org page without an active superuser session gets stuck in an infinite loop. The page keeps refetching the org bootstrap requests and /api/0/authenticators/, and the sudo modal spinner never resolves, so they can't elevate.

Why

#129199 added an incrementing modalId to ModalStore and renders the modal content inside <ErrorBoundary key={modalId}>. Every openModal call now remounts the whole modal subtree. Before, a second openModal with the same component type reconciled in place.

OrganizationContextProvider calls openSudo from an effect on [user, error, organization] whenever user.isSuperuser && error.status === 403. That interacts badly with the remount:

1. Org bootstrap 403s → effect calls openSudo → SudoModal mounts.
2. On mount, SudoModal subscribes to the bootstrap org/teams/projects queries, which refetch because they errored.
3. Each 403 sets a new error object in OrganizationStore → the effect re-runs → openSudo → modalId increments → SudoModal remounts → go to 2.

SudoModal waits for the bootstrap queries to settle before it fetches authenticators, so it never gets past the loading state.

Evidence

• Prod: the frontend console log for the org-details 403 (GET /organizations/{orgSlug}/ 403 … You do not have permission) jumped from about 8 per session to about 118k lines from 23 employees, starting at about 12:56 UTC on 2026-11-03, shortly after fix(modal): Contain render errors within the dialog #129199 merged at 12:09 UTC. That's roughly 1000× baseline.
• Jest repro: a superuser, a plain 403 ({"detail": "You do not have permission to perform this action."}) on /organizations/org-slug/, /teams/ and /projects/, rendering OrganizationContextProvider + GlobalModal with the real sudo modal, then waiting 2s:
  • master: 4666 org-details requests, 0 authenticators requests, password form never renders
  • this revert: 2 org-details requests, 1 authenticators request, password form renders

Changes

• git revert a976243287050cb02bb60520bc4818370ed3567d. It applies cleanly and restores the 5 files touched by fix(modal): Contain render errors within the dialog #129199 to their exact pre-fix(modal): Contain render errors within the dialog #129199 contents. Nothing else reads modalId.
• Adds static/app/views/organizationContextSudo.spec.tsx, a small regression test for the scenario above without the sleep. It waits for the password field and asserts the org request ran at most 3 times. It needs its own file because organizationContext.spec.tsx mocks openSudo. It fails on master (the password field never appears) and passes on this branch, about 3s per run and 3/3 stable locally.

Re-landing #129199

Either of these should let the error containment come back without the loop:

• Only re-key the ErrorBoundary when it's actually showing an error (reset it on a new modalId without changing key), so a normal re-open still reconciles in place.
• And/or make OrganizationContextProvider skip openSudo while a sudo modal is already open, so repeated 403s don't re-open it.

Ideally, the re-land keeps the regression test from this PR.

Verification

• jest on core/modal/index.spec.tsx, errorBoundary.spec.tsx, modals/sudoModal.spec.tsx, views/organizationContext.spec.tsx, views/organizationContextSudo.spec.tsx: 5 suites, 38 tests passed. There is no modalStore spec.
• pnpm run typecheck: passed
• pnpm run lint:js and oxfmt --check on touched files: clean

via @lcian.

--

View Session [Sentry]