Revert "feat(triage signals): Remove fixability from run_automation and put into _generate_summary" #103663
Conversation
…nd put i…" This reverts commit 699b63a.
github-actions
bot
added
the
Scope: Backend
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| with sentry_sdk.start_span(op="ai_summary.generate_fixability_score"): | ||
| issue_summary = _generate_fixability_score(group) | ||
|
|
||
| if not issue_summary.scores: | ||
| raise ValueError("Issue summary scores is None or empty.") | ||
| if issue_summary.scores.fixability_score is None: | ||
| raise ValueError("Issue summary fixability score is None.") | ||
|
|
||
| group.update(seer_fixability_score=issue_summary.scores.fixability_score) |
There was a problem hiding this comment.
Bug: The _generate_fixability_score function is unconditionally called in _run_automation, causing redundant Seer API requests.
Severity: CRITICAL | Confidence: High
🔍 Detailed Analysis
The _generate_fixability_score function, which makes an expensive signed HTTP request to the Seer API, is now unconditionally called within _run_automation (lines 317-325). This occurs on every automation trigger, even if group.seer_fixability_score is already populated, leading to increased load on the Seer API, unnecessary latency, and reduced reliability. This regression likely caused canary deploy failures due to timeouts or rate limiting.
💡 Suggested Fix
Reintroduce a check within _run_automation to only call _generate_fixability_score if group.seer_fixability_score is None or if the source explicitly requires a fresh score, similar to the previous guarded logic.
🤖 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/seer/autofix/issue_summary.py#L317-L325
Potential issue: The `_generate_fixability_score` function, which makes an expensive
signed HTTP request to the Seer API, is now unconditionally called within
`_run_automation` (lines 317-325). This occurs on every automation trigger, even if
`group.seer_fixability_score` is already populated, leading to increased load on the
Seer API, unnecessary latency, and reduced reliability. This regression likely caused
canary deploy failures due to timeouts or rate limiting.
Did we get this right? 👍 / 👎 to inform future reviews.
Reference_id: 2817270
Reverts #103485
Broke canary deploy in DE: https://deploy.getsentry.net/go/tab/build/detail/deploy-getsentry-backend-de/9966/deploy-canary/1/deploy-backend