ref(seer): Remove should_run_automation from get_issue_summary#112219
ref(seer): Remove should_run_automation from get_issue_summary#112219
Conversation
Move the run_automation call out of get_issue_summary and into the generate_summary_and_run_automation task, where the intent is explicit. This removes a hidden side effect from what should be a summary-only function and lets callers decide whether to trigger automation. Also renames generate_issue_summary_only to generate_summary_and_fixability_score to better reflect what it does. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
| ) | ||
|
|
||
| return summary_dict, 200 | ||
| return summary_dict, 200, event |
There was a problem hiding this comment.
Moved the automation responsibility to the calling spot, it was getting too complicated tracing all the various paths and implicit behavior.
There was a problem hiding this comment.
We can't remove this here. The old Seer SKU (not per seat orgs) still use this flow.
It is the "old Seer" in this diagram - https://miro.com/app/board/uXjVJqn1-fQ=/?focusWidget=3458764648325594380
There was a problem hiding this comment.
I think that should still be preserved.
def kick_off_seer_automation(job: PostProcessJob) -> None:
...
if not is_seer_seat_based_tier_enabled(group.organization):
generate_summary_and_run_automation.delay(group.id, trigger_path="old_seer_automation")
def generate_summary_and_run_automation(group_id: int, **kwargs) -> None:
if status_code == 200 and event is not None:
run_automation(group, AnonymousUser(), event, SeerAutomationSource.POST_PROCESS)
The generate_summary_and_run_automation() func now explicitly calls run_automation() instead of relying on get_issue_summary() to call it.
| retry=Retry(times=3, delay=3, on=(Exception,)), | ||
| ) | ||
| def generate_issue_summary_only(group_id: int) -> None: | ||
| def generate_summary_and_fixability_score(group_id: int) -> None: |
There was a problem hiding this comment.
Can revert the naming if you find it confusing to not match the task name, but the _only suffix was really confusing to read when it clearly does not only generate the summary lol.
This error handler was never triggered in production. Removing it lets the task retry mechanism handle failures instead of silently swallowing them. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Two early returns in get_issue_summary (feature flag disabled, AI features hidden) were still returning 2-tuples after the signature changed to 3-tuples. Also fixes two test mocks for _generate_summary with the same issue. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…loss On retry, the summary is cached so get_issue_summary returns event=None, causing the automation guard to skip entirely. Catching the exception prevents a wasted retry and logs the failure instead of silently dropping automation. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
get_issue_summary no longer calls run_automation, so the _trigger_autofix_task and get_autofix_state patches and assertions were stale. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Missed caller of get_issue_summary that was still unpacking 2 values instead of 3. Would have caused ValueError at runtime for Slack alert notifications. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Backend Test FailuresFailures on
|
Several test files were still mocking get_issue_summary with 2-tuple return values instead of 3-tuples: the endpoint error test, Slack message builder tests, and issue_summary_for_alerts tests. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
| from django.contrib.auth.models import AnonymousUser | ||
|
|
||
| from sentry.seer.autofix.issue_summary import get_issue_summary, run_automation |
There was a problem hiding this comment.
do these imports need to be inlined or can they go to top of file?
There was a problem hiding this comment.
post_process.py is very picky about imports which is why this is all inlined.
Mihir-Mavalankar
left a comment
There was a problem hiding this comment.
kick_off_seer_automation still needs to support Seer customers on the old plan. I think these changes break that
| ) | ||
|
|
||
| return summary_dict, 200 | ||
| return summary_dict, 200, event |
There was a problem hiding this comment.
We can't remove this here. The old Seer SKU (not per seat orgs) still use this flow.
It is the "old Seer" in this diagram - https://miro.com/app/board/uXjVJqn1-fQ=/?focusWidget=3458764648325594380
| try: | ||
| run_automation(group, AnonymousUser(), event, SeerAutomationSource.POST_PROCESS) | ||
| except Exception: | ||
| logger.exception("seer.automation.run_automation_failed", extra={"group_id": group.id}) |
There was a problem hiding this comment.
I think this issue warden caught is correct.
There was a problem hiding this comment.
From what I can tell this issue is present in the old code as well. get_issue_summary() checks:
# 1. Check cache first
if cached_summary := cache.get(cache_key):
return convert_dict_key_case(cached_summary, snake_to_camel_case), 200
which early returns before the automation gets triggered. We can fix if you think this is a bug but trying to keep this PR having no behavior changes.
There was a problem hiding this comment.
Although to Warden's point maybe this should be named generate_summary_and_maybe_run_automation()
|
Also maybe this PR is worth breaking down into 2 things:
|
source was only used to pass to run_automation which was removed from this function. get_issue_summary still accepts source for billing logging. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…e_summary The refactor to return event from get_issue_summary removed the run_automation call that was previously embedded in _generate_summary. This restores the ALERT automation path by calling run_automation explicitly after a successful summary generation. Co-Authored-By: Claude Opus 4.6 <noreply@example.com>
There was a problem hiding this comment.
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 901ed71. Configure here.
| logger.exception( | ||
| "seer.automation.run_automation_failed", | ||
| extra={"group_id": group.id}, | ||
| ) |
There was a problem hiding this comment.
Alert path runs automation without timeout protection
Medium Severity
The run_automation call, which makes HTTP requests to the Seer API, now runs synchronously on the main thread after the timed issue summary generation. This work is no longer covered by the timeout, allowing slow Seer responses to block the alert notification thread.
Reviewed by Cursor Bugbot for commit 901ed71. Configure here.


get_issue_summarywas doing too much — generating the summary, caching it,and optionally triggering automation via a
should_run_automationboolean flag.This made it misleading as a "get" function and hid a significant side effect
behind a default parameter.
This PR moves the
run_automationcall out ofget_issue_summaryand intogenerate_summary_and_run_automation, the task that actually wants automation.Callers now explicitly decide whether to run automation after getting a summary.
get_issue_summarynow returns a 3-tuple(summary_data, status_code, event)so callers that need the event for automation have access to it.
Also renames
generate_issue_summary_only→generate_summary_and_fixability_scoreto better describe what the task does (the Celery task name string is unchanged).
Note: the
GroupAiSummaryEndpointpreviously passedshould_run_automation=True(the default) but used
source=SeerAutomationSource.ISSUE_DETAILS.run_automationhas an early return for that source (
if source == ISSUE_DETAILS: return), soautomation was never actually triggered from that endpoint — the flag was a no-op
there. This refactor doesn't change that behavior.