[sentry-junior]

sentry django migrate spends ~20s rebuilding migration state before it does anything, even with nothing to apply.

SafeDeleteModel / SafeRemoveField with MOVE_TO_PENDING looked the model up through state.apps, and SentryProjectState.remove_model / remove_field did the same to stash a rendered model or field. Since #127458 drops the rendered registry at each migration boundary, every migration with a pending deletion rendered every model from scratch. Replaying the history does that once per past pending deletion, and migrate replays it up to three times (pre-migrate state, executor state, autodetector check).

SentryProjectState now keeps the pending ModelState and the unbound field as they are. get_pending_deletion_model / get_pending_deletion_field render them only when a DELETE step (or its backwards) needs them, in a throwaway clone of the state, so the replay never renders. The state_forwards safety checks read the ModelState fields directly. Because nothing renders during replay any more, the CheckedMigration.mutate_state workaround from #127458 is removed.

Rendering later means a pending model's relations have to resolve against a later state. investigations/0008 and 0017 DELETE an M2M through model before the model that declares it, so models whose DELETE already ran are kept in deleted_models and added back when a pending deletion points at them. All 61 DELETE operations in the current history resolve to the same tables, columns, and through tables as before; I compared them against master.

tools/migrations/drop_pending_deletions.py uses the new render_pending_deletions(), so it renders everything once instead of reading stored model classes.

Timings on a full dev environment, two runs each. "2 pending" is sentry.1254 (a real SafeRemoveField DELETE of grouprelease.new_release_id) plus sentry.1255:

sentry django migrate	before	after
nothing to apply	30.0s / 31.6s	6.8s / 7.6s
2 pending	18.5s / 18.2s	6.8s / 7.1s

Under cProfile, with nothing to apply: 76 full StateApps renders (21,228 ModelState.render calls, 29.6s) before, and 1 render (336 calls, 0.8s) after. MigrationLoader.project_state() alone drops from 9.8s to 0.2s.

Changed test expectation: moving a model to pending twice now raises Django's usual LookupError: App '…' doesn't have a 'TestTable' model. instead of No installed app with label …, which came from rendering a fresh registry.

The full migration suite passes with --create-db, which applies every historical DELETE against a real database. So do tests/sentry/new_migrations, the safe-migrations integration tests, and tests/sentry/runner/commands/test_migrations.py. Unapplying sentry.1254 adds the column back.

via Ming Chen.

--

View Session [Sentry]

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 2c14d75. Configure here.}