chore(autofix): Emit seer opened event when starting analysis#115595
chore(autofix): Emit seer opened event when starting analysis#115595Zylphrex wants to merge 2 commits into
Conversation
Starting the analysis also opens the drawer so make sure to emit the same event.
github-actions
Bot
added
the
Scope: Frontend
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
📊 Type Coverage Diff✅ No new type safety issues introduced. Coverage: 93.52% |
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| analyticsParams={{ | ||
| group_id: group.id, | ||
| has_streamlined_ui: true, | ||
| autofix_exists: false, | ||
| autofix_step_type: null, | ||
| has_summary: false, | ||
| has_root_cause: false, | ||
| has_solution: false, | ||
| has_coded_solution: false, | ||
| has_pr: false, | ||
| }} |
There was a problem hiding this comment.
Bug: The issue_details.seer_opened analytics event fires on button click, even if the asynchronous operation to open the Seer drawer fails, leading to inaccurate analytics.
Severity: LOW
Suggested Fix
Move the analytics tracking to after the asynchronous operation has successfully completed. Instead of using the analyticsEventKey prop on the Button, manually fire the issue_details.seer_opened event inside the handleStartRootCause function after the await startStep(...) call succeeds.
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: static/app/views/issueDetails/streamline/sidebar/autofixSection.tsx#L312-L327
Potential issue: The `Button` component has an `analyticsEventKey` prop that fires the
`issue_details.seer_opened` event immediately on click. The `onClick` handler,
`handleStartRootCause`, then calls the asynchronous function `startStep`. If this
`startStep` call fails, an error is caught, and the function returns before
`openSeerDrawer()` is called. This results in the analytics event being recorded even
when the Seer drawer fails to open, skewing analytics data.
Did we get this right? 👍 / 👎 to inform future reviews.
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 368d26c. Configure here.
| has_pr: false, | ||
| mode: 'explorer', | ||
| referrer, | ||
| }} |
There was a problem hiding this comment.
Seer opened event fires even when drawer doesn't open
Low Severity
The issue_details.seer_opened event is emitted via the button's built-in analytics on every click, but the drawer only opens if startStep('root_cause') succeeds. When startStep throws, the catch block returns early and openSeerDrawer() is never called, yet the "seer opened" event has already been sent. The other usage of this event (the "Open Autofix" button) calls openSeerDrawer directly, so the event always matches reality there. This will inflate "seer opened" analytics counts when analysis fails to start.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 368d26c. Configure here.
1 participant
Starting the analysis also opens the drawer so make sure to emit the same event.