feat(weekly-report): Add "Past Resolved Issues" by amy-chen23 · Pull Request #117751 · getsentry/sentry

amy-chen23 · 2026-06-15T21:45:46Z

Resolves ID-1622

To test:

Start dev environment
Go to debug/mail/weekly-reports/

Summary

Add "past issues" section showing the top 3 most relevant resolved issues from the past week
Query both error (events dataset) and performance (search_issues dataset) resolved groups, merge event counts, and enrich with GroupLink data via a single org-level batched query
Weigh issues resolved by linked commits/PRs more -- score relevance as event_count * 2 for issues linked to commits/PRs, event_count * 1 otherwise
Gated behind organizations:weekly-report-past-issues feature flag

Backend Changes

src/sentry/tasks/summaries/utils.py — Add project_past_resolved_issues(), Snuba count helpers for error/perf datasets, fetch_past_resolved_issue_links() for org-level GroupLink enrichment
src/sentry/tasks/summaries/organization_report_context_factory.py — Wire new pipeline behind feature flag, skip old key_errors/key_performance_issues when flag is on
src/sentry/tasks/summaries/weekly_reports.py — Add past_issues() template context with relevance-boosted ranking

Frontend Changes

Added section to body.html
The RHS will always so "resolved", but still waiting on frontend PR for those changes
Should render like this:

Validation / edge cases

If there are no resolved issues from the past week, we don't show any past issues

amy-chen23 · 2026-06-15T23:25:54Z

    REPORTS_KEY_ERRORS = "reports.key_errors"
    REPORTS_KEY_ERRORS_BATCHED = "reports.key_errors.batched"
    REPORTS_KEY_PERFORMANCE_ISSUES = "reports.key_performance_issues"
+    REPORTS_PAST_RESOLVED_ISSUES = "reports.past_resolved_issues"


i'm open to combining all referrers into one "WEEKLY_REPORT" referrer to remove all the clutter

I would talk to the EAP team before doing that.

cursor · 2026-06-15T23:37:50Z

                self._hydrate_key_error_groups(ctx)
                self._hydrate_key_performance_issue_groups(ctx)
+                if features.has("organizations:weekly-report-past-issues", self.organization):
+                    self._append_project_past_resolved_issues(ctx)


Flag on still runs key errors

Medium Severity

With organizations:weekly-report-past-issues enabled, the report still builds unresolved key_errors and key_performance_issues and always puts them in the email context, while also populating past_issues. That contradicts replacing those sections with past resolved issues and wastes Snuba work on every flagged org.

Additional Locations (1)

src/sentry/tasks/summaries/weekly_reports.py#L802-L805

^{Reviewed by Cursor Bugbot for commit 0cdad91. Configure here.}

end goal is to replace key_errors and key_performance_issues. however, for now, we'll append this section

markstory · 2026-06-16T14:49:32Z

    REPORTS_KEY_ERRORS = "reports.key_errors"
    REPORTS_KEY_ERRORS_BATCHED = "reports.key_errors.batched"
    REPORTS_KEY_PERFORMANCE_ISSUES = "reports.key_performance_issues"
+    REPORTS_PAST_RESOLVED_ISSUES = "reports.past_resolved_issues"


I would talk to the EAP team before doing that.

markstory · 2026-06-16T14:51:09Z

+        error_group_ids = [g.id for g in candidates if g.type is None or g.type < 1000]
+        perf_group_ids = [g.id for g in candidates if g.type is not None and 1000 <= g.type < 2000]


What are 1000 and 2000? Are there enum or constant values you could reference instead?

Yup, i'll filter by issue_category == GroupCategory.ERROR and issue_category == GroupCategory.PERFORMANCE instead

cursor

Cursor Bugbot has reviewed your changes and found 2 potential issues.

There are 3 total unresolved issues (including 1 from previous review).

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

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

linear-code · 2026-06-16T20:53:10Z

ID-1622

… issues

…gic numbers

shashjar · 2026-06-18T16:32:53Z

+                project_id=project.id,
+                status=GroupStatus.RESOLVED,
+                resolved_at__gte=ctx.start,
+                resolved_at__lt=ctx.end + timedelta(days=1),


what's the reason for adding a day of buffer here?

the previous queries for weekly report have always added the day buffer. my guess is that previously, there might have been issues with late-day events being excluded

shashjar · 2026-06-18T16:33:39Z

        project_ctx.total_substatus_count += item["total"]
+
+
+_PAST_ISSUES_CANDIDATE_LIMIT = 50


nit: you don't have to _ prefix these

shashjar · 2026-06-18T16:36:15Z

+                Op.EQ,
+                GroupStatus.RESOLVED,
+            ),
+            Condition(Column("level", entity=events_entity), Op.EQ, "error"),


hmm i see the old queries do this as well but i think filtering on level: error actually might be wrong / unnecessary

agree. if we remove the filter, we count events with levels "error", "warning", "info", "debug", and "fatal" which seems more correct. since we want to prioritize issues with the most activity

shashjar · 2026-06-18T16:38:38Z

+            for group, count, _has_link in project_ctx.past_resolved_issues
+        ]
+
+    # Re-sort with link boost applied, then truncate to top 3


what would be cool is if we had an abstracted search API which allowed for arbitrary postgres and snuba conditions to both be taken into consideration for filtering and sorting, and you just get back the appropriate results based on your query

@roggenkemper we don't have anything like this right?

i dont think so

sounds interesting -- how much would this overlap with the recommended sort?

shashjar · 2026-06-18T16:39:45Z

+_PAST_ISSUES_LINK_BOOST = 2
+
+
+def project_past_resolved_issues(


i forgot - how did we manage the per-org batched requests for key/current errors? are we unable to use the same approach to batch the past issues queries?

currently we're querying snuba per org per project (like how we queried pre-batch). The problem implementing it here is that we have a max of 50 group IDs to query. If we batch by 100, then we're querying for 5000 group IDs. so there are tradeoffs :(

we're implementing batching this weekend, so maybe we see how much it improves performance before we implement a similar logic here?

shashjar · 2026-06-18T16:41:13Z

        return heapq.nlargest(3, all_key_performance_issues(), lambda d: d["count"])

+    def past_issues():
+        from sentry.tasks.summaries.utils import _PAST_ISSUES_LINK_BOOST


nit: can we put at top of file?

sentry · 2026-06-18T17:29:47Z

+                    past_issues.append(
+                        {
+                            "count": count,
+                            "group": group,
+                            "title": display["title"],
+                            "message": display["message"],
+                            "has_linked_pr_or_commit": has_link,
+                        }
+                    )
+            past_issues.sort(key=lambda x: x["count"], reverse=True)
+            context["past_issues"] = past_issues[:3]


Bug: The debug view for weekly reports sorts past issues by count, while production uses a relevance score, causing a misleading preview of the issue order.
_{Severity: LOW}

Suggested Fix

Update the debug view's sorting logic to match the production logic. Calculate a _relevance score for each past issue using the formula count * (PAST_ISSUES_LINK_BOOST if has_linked_pr_or_commit else 1) and sort the past_issues list based on this score before slicing the top results.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: src/sentry/web/frontend/debug/debug_weekly_report.py#L227-L241 Potential issue: The debug view for weekly reports at `debug/mail/weekly-reports/` sorts past resolved issues by their raw `count`. However, the production code that generates the actual email sorts these issues using a `_relevance` score, calculated as `count * (PAST_ISSUES_LINK_BOOST if has_linked_pr_or_commit else 1)`. This discrepancy means the debug preview, which is intended for testing, will show a different and incorrect ordering of issues compared to the final email whenever an issue's rank is affected by the link boost, making the preview unreliable.

Also affects:

src/sentry/tasks/summaries/weekly_reports.py:783-798

preview is for frontend changes, populates with fake info anyway

github-actions Bot added the Scope: Backend Automatically applied to PRs that change backend components label Jun 15, 2026

sentry-warden Bot reviewed Jun 15, 2026

View reviewed changes

Comment thread src/sentry/tasks/summaries/organization_report_context_factory.py

amy-chen23 changed the title ~~feat(weekly-report): backend changes for merging resolved error + performance issues~~ feat(weekly-report): Add "Past Resolved Issues" backend Jun 15, 2026

amy-chen23 commented Jun 15, 2026

View reviewed changes

amy-chen23 marked this pull request as ready for review June 15, 2026 23:35

amy-chen23 requested review from a team as code owners June 15, 2026 23:35

cursor Bot reviewed Jun 15, 2026

View reviewed changes

amy-chen23 mentioned this pull request Jun 16, 2026

feat(weekly-report): Add frontend changes to past issues section #117773

Closed

markstory reviewed Jun 16, 2026

View reviewed changes

amy-chen23 requested a review from a team June 16, 2026 16:34

cursor Bot reviewed Jun 16, 2026

View reviewed changes

Comment thread src/sentry/tasks/summaries/utils.py

Comment thread src/sentry/tasks/summaries/utils.py

amy-chen23 marked this pull request as draft June 16, 2026 20:52

amy-chen23 changed the title ~~feat(weekly-report): Add "Past Resolved Issues" backend~~ feat(weekly-report): Add "Past Resolved Issues" Jun 16, 2026

sentry-warden Bot reviewed Jun 16, 2026

View reviewed changes

Comment thread src/sentry/tasks/summaries/organization_report_context_factory.py

amy-chen23 marked this pull request as ready for review June 17, 2026 21:36

amy-chen23 requested a review from a team as a code owner June 17, 2026 21:36

sentry Bot reviewed Jun 17, 2026

View reviewed changes

Comment thread src/sentry/tasks/summaries/utils.py

amy-chen23 added 10 commits June 17, 2026 15:33

backend changes for merging resolved error + performance issues

94038b4

make past issues an additive section, keep existing key errors + perf…

1b8f1e1

… issues

apply link-boost before top-3 truncation in past issues

a3dbbde

filtering error and performance issues by issue_category to remove ma…

4d96c3a

…gic numbers

link boost only applies to issues with resolved links

265cde2

using same boundary as other queries

a8bc323

handle legacy groups with unregistered type ids

1de9a47

adding "resolved this week" to frontend

ec6b23f

fixing typing errors

2b9ea09

fixing typing issues 2

188b042

update formatting to match new UI

73111da

amy-chen23 marked this pull request as draft June 17, 2026 22:40

amy-chen23 force-pushed the amyc/past-issues-weekly-report-backend branch from 9563adb to 73111da Compare June 17, 2026 22:49

amy-chen23 marked this pull request as ready for review June 17, 2026 22:53

sentry Bot reviewed Jun 17, 2026

View reviewed changes

Comment thread src/sentry/tasks/summaries/weekly_reports.py

shashjar requested a review from roggenkemper June 18, 2026 16:38

shashjar approved these changes Jun 18, 2026

View reviewed changes

changed filtering and var names

dcefbb9

sentry Bot reviewed Jun 18, 2026

View reviewed changes

amy-chen23 merged commit 3d13198 into master Jun 18, 2026
85 checks passed

amy-chen23 deleted the amyc/past-issues-weekly-report-backend branch June 18, 2026 21:37

		error_group_ids = [g.id for g in candidates if g.type is None or g.type < 1000]
		perf_group_ids = [g.id for g in candidates if g.type is not None and 1000 <= g.type < 2000]

		project_ctx.total_substatus_count += item["total"]


		_PAST_ISSUES_CANDIDATE_LIMIT = 50

		_PAST_ISSUES_LINK_BOOST = 2


		def project_past_resolved_issues(

Uh oh!

Conversation

amy-chen23 commented Jun 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Backend Changes

Frontend Changes

Validation / edge cases

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cursor Bot Jun 15, 2026

Choose a reason for hiding this comment

Flag on still runs key errors

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

linear-code Bot commented Jun 16, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sentry Bot Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

amy-chen23 commented Jun 15, 2026 •

edited

Loading