-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(grouping): Store metadata for new grouphashes #76245
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅ ✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## master #76245 +/- ##
=======================================
Coverage 78.20% 78.20%
=======================================
Files 6895 6895
Lines 306372 306384 +12
Branches 50227 50229 +2
=======================================
+ Hits 239608 239621 +13
+ Misses 60358 60355 -3
- Partials 6406 6408 +2 |
c292ef5
to
448c15d
Compare
806dcbe
to
6f7b8f8
Compare
6f7b8f8
to
0b44df4
Compare
0b44df4
to
a546e1e
Compare
5e5026a
to
810370e
Compare
a546e1e
to
e12caf6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
talked during meeting, should ramp up writes slowly just to be safe
810370e
to
a3bc7a6
Compare
e12caf6
to
47426f0
Compare
Yup - you beat me by about two minutes. 🙂 Just pushed it again, including a feature flag. UPDATE: Here's the PR with the actual config: https://github.com/getsentry/sentry-options-automator/pull/2189. |
…76572) This is a follow-up to #76312, fixing another bug with grouphash deletion. Currently, when a project is deleted, its associated `GroupHash` records are deleted directly by the project deletion task, using the `BulkModelDeletionTask`. Unfortunately, that task doesn't take into account any dependent tables, meaning that the corresponding `GroupHashMetadata` records aren't deleted as they should be. This fixes that by allowing `GroupHash` deletions to cascade from group deletions (which themselves are set off by project deletion), rather than having the project deletion task delete the grouphashes directly. (Group deletions already handle `GroupHash`/`GroupHashMetadata` deletion correctly, using the `GroupHash`-specific deletion task registered in the deletion module's `__init__.py`[1].) Note that while the results of this change aren't tested in this PR, they are implicitly tested in #76245, which will directly follow this one and which for the first time will actually create `GroupHashMetadata` records. Without the change in this PR, the presence of that PR's new `GroupHashMetadata` records causes the project deletion test to fail, but with this change, they pass. [1] https://github.com/getsentry/sentry/blob/9155480cddb7454bba99ae39ea4caac91261ca26/src/sentry/deletions/__init__.py#L127
47426f0
to
e85e583
Compare
As part of the rollout of the new grouphash metadata table, this creates a
GroupHashMetadata
row for every newGroupHash
we create. It's gated by a killswitch and a feature flag, and doesn't do much yet - the only data in the table so far is a creation timestamp - but this should give us a sense of whether or not there's going to be any hit to ingest DB performance.