fix(deletions): Break circular reference in GroupHistory #102470
Merged
+39
−2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When deleting a GroupHistory record, Django would CASCADE to all records that reference it via `prev_history`, which can create circular dependency loops. After this change, Django will just set prev_history=NULL on any records that reference it, breaking the circular chain. Fixes [SENTRY-3WN8](https://sentry.sentry.io/issues/6619377437/) and [SENTRY-3WKX](https://sentry.sentry.io/issues/6618890707/).
github-actions
bot
added
the
Scope: Backend
Contributor
|
This PR has a migration; here is the generated SQL for for --
-- Alter field prev_history on grouphistory
--
-- (no-op) |
Member
Author
|
I prefer removing the field completely: #102473 |
Member
Author
|
That other PR will take multiple steps. Let's start with getting this one out the door. |
armenzg
added a commit
that referenced
this pull request
Oct 31, 2025
While investigating #102470, I realized we don't actually use it for anything useful. In order to delete the column, we first need to stop making any reference to it ([docs](https://develop.sentry.dev/backend/application-domains/database-migrations/#deleting-columns).
markstory
approved these changes
Oct 31, 2025
Member
markstory
left a comment
markstory
left a comment
There was a problem hiding this comment.
looks good to me. Instead of recursing deletes, django will only have to modify the one adjacent record.
isabellaenriquez
pushed a commit
that referenced
this pull request
Oct 31, 2025
When deleting a GroupHistory record, Django would CASCADE to all records that reference it via `prev_history`, which can create circular dependency loops. After this change, Django will just set prev_history=NULL on any records that reference it, breaking the circular chain. Fixes [SENTRY-3WN8](https://sentry.sentry.io/issues/6619377437/) and [SENTRY-3WKX](https://sentry.sentry.io/issues/6618890707/).
armenzg
added a commit
that referenced
this pull request
Oct 31, 2025
While investigating #102470, I realized we don't actually use it for anything useful. In order to delete the column, we first need to stop making use of it (see [docs](https://develop.sentry.dev/backend/application-domains/database-migrations/#deleting-columns) for instructions).
jjbayer
pushed a commit
that referenced
this pull request
Nov 3, 2025
While investigating #102470, I realized we don't actually use it for anything useful. In order to delete the column, we first need to stop making use of it (see [docs](https://develop.sentry.dev/backend/application-domains/database-migrations/#deleting-columns) for instructions).
armenzg
added a commit
that referenced
this pull request
Nov 3, 2025
This is how it used to be before #76608. Now that we have fixed the circular relationship (#102470) I believe we should give this approach another attempt. Fixes [SENTRY-5BX2](https://sentry.sentry.io/issues/6993998110/): For posterity: ``` OperationalError canceling statement due to user request SQL: SELECT "sentry_grouphistory"."id" AS "id" FROM "sentry_grouphistory" WHERE "sentry_grouphistory"."group_id" = %s ORDER BY 1 ASC LIMIT 100 ``` The group in question has only been seen 4 times yet it has 905,729 rows of group history.
armenzg
added a commit
that referenced
this pull request
Nov 3, 2025
This is how it used to be before #76608. Now that we have fixed the circular relationship (#102470) I believe we should give this approach another attempt. Fixes [SENTRY-5BX2](https://sentry.sentry.io/issues/6993998110/): For posterity: ``` OperationalError canceling statement due to user request SQL: SELECT "sentry_grouphistory"."id" AS "id" FROM "sentry_grouphistory" WHERE "sentry_grouphistory"."group_id" = %s ORDER BY 1 ASC LIMIT 100 ``` The group in question has only been seen 4 times yet it has 905,729 rows of group history. This is caused by the priority of the group changing back and forth between high and medium priority. We're investigating the root cause of it.
shashjar
pushed a commit
that referenced
this pull request
Nov 4, 2025
When deleting a GroupHistory record, Django would CASCADE to all records that reference it via `prev_history`, which can create circular dependency loops. After this change, Django will just set prev_history=NULL on any records that reference it, breaking the circular chain. Fixes [SENTRY-3WN8](https://sentry.sentry.io/issues/6619377437/) and [SENTRY-3WKX](https://sentry.sentry.io/issues/6618890707/).
shashjar
pushed a commit
that referenced
this pull request
Nov 4, 2025
While investigating #102470, I realized we don't actually use it for anything useful. In order to delete the column, we first need to stop making use of it (see [docs](https://develop.sentry.dev/backend/application-domains/database-migrations/#deleting-columns) for instructions).
shashjar
pushed a commit
that referenced
this pull request
Nov 4, 2025
This is how it used to be before #76608. Now that we have fixed the circular relationship (#102470) I believe we should give this approach another attempt. Fixes [SENTRY-5BX2](https://sentry.sentry.io/issues/6993998110/): For posterity: ``` OperationalError canceling statement due to user request SQL: SELECT "sentry_grouphistory"."id" AS "id" FROM "sentry_grouphistory" WHERE "sentry_grouphistory"."group_id" = %s ORDER BY 1 ASC LIMIT 100 ``` The group in question has only been seen 4 times yet it has 905,729 rows of group history. This is caused by the priority of the group changing back and forth between high and medium priority. We're investigating the root cause of it.
priscilawebdev
pushed a commit
that referenced
this pull request
Nov 6, 2025
This is how it used to be before #76608. Now that we have fixed the circular relationship (#102470) I believe we should give this approach another attempt. Fixes [SENTRY-5BX2](https://sentry.sentry.io/issues/6993998110/): For posterity: ``` OperationalError canceling statement due to user request SQL: SELECT "sentry_grouphistory"."id" AS "id" FROM "sentry_grouphistory" WHERE "sentry_grouphistory"."group_id" = %s ORDER BY 1 ASC LIMIT 100 ``` The group in question has only been seen 4 times yet it has 905,729 rows of group history. This is caused by the priority of the group changing back and forth between high and medium priority. We're investigating the root cause of it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When deleting a GroupHistory record, Django would CASCADE to all records that reference it via
prev_history, which can create circular dependency loops.After this change, Django will just set prev_history=NULL on any records that reference it, breaking the circular chain.
Fixes SENTRY-3WN8 and SENTRY-3WKX.