feat(issues): Record Seer events for display in the issue activity timeline#115486
Conversation
| # Show Seer run ID in Slack notification footers | ||
| manager.add("organizations:seer-run-id-in-slack", OrganizationFeature, FeatureHandlerStrategy.FLAGPOLE, api_expose=False) | ||
| # Enable Seer activity events in the issue activity timeline | ||
| manager.add("organizations:seer-activity-timeline", OrganizationFeature, FeatureHandlerStrategy.FLAGPOLE, api_expose=True) |
There was a problem hiding this comment.
Using an org-level feature flag to gate for initial rollout
| Activity.objects.create_group_activity( | ||
| group, | ||
| activity_type, | ||
| data=activity_data if activity_data else None, |
There was a problem hiding this comment.
Open to thoughts on exactly what metadata we want to include on the Activitys for each of these event types
There was a problem hiding this comment.
Would suggest to merge this as is then figure it out as we want things.
One thing that might be useful is the referrer (what caused Autofix to run) but off the top of my head that's the only thing.
There was a problem hiding this comment.
+1 ^^^
Also agree that having a referrer here would be nice.
There was a problem hiding this comment.
Yeah agreed - I was thinking something similar on @Jesse-Box's draft of activity types in order to collapse PR triggered / PR created (and similar states) into a single thing which is further differentiated by a referrer
| SentryAppEventType.SEER_SOLUTION_COMPLETED: ActivityType.SEER_SOLUTION_COMPLETED, | ||
| SentryAppEventType.SEER_CODING_STARTED: ActivityType.SEER_CODING_STARTED, | ||
| SentryAppEventType.SEER_CODING_COMPLETED: ActivityType.SEER_CODING_COMPLETED, | ||
| SentryAppEventType.SEER_PR_CREATED: ActivityType.SEER_PR_CREATED, |
There was a problem hiding this comment.
We might want PR merged eventually but looks like we're generally missing the plumbing for that so it can come later.
…activity-timeline
| if event_type == SentryAppEventType.SEER_ROOT_CAUSE_COMPLETED: | ||
| if "root_cause" in event_payload: | ||
| activity_data["root_cause"] = event_payload["root_cause"] | ||
| elif event_type == SentryAppEventType.SEER_SOLUTION_COMPLETED: | ||
| if "solution" in event_payload: | ||
| activity_data["solution"] = event_payload["solution"] | ||
| elif event_type == SentryAppEventType.SEER_CODING_COMPLETED: | ||
| if "changes" in event_payload: | ||
| activity_data["changes"] = event_payload["changes"] | ||
| elif event_type == SentryAppEventType.SEER_PR_CREATED: | ||
| if "pull_requests" in event_payload: | ||
| activity_data["pull_requests"] = event_payload["pull_requests"] |
There was a problem hiding this comment.
we should probably also just do these in one line:
elif event_type == SentryAppEventType.SEER_SOLUTION_COMPLETED:
activity_data["solution"] = event_payload.get("solution")
Could we normalize the event_payload here so that these are all a generic data or seer_result or something? that way we can just have this be one line of code: activity_data["result"] = event_payload.get("seer_result") kind of thing.
There was a problem hiding this comment.
You mean normalize the event payload Seer-side when the events get sent? I'm supportive of that - @chromy any thoughts?
There was a problem hiding this comment.
yeah, although i think we can reduce this down to 1 line of code per if statement w/o normalizing from seer.
There was a problem hiding this comment.
oh yea good point, will clean that up thanks
| Activity.objects.create_group_activity( | ||
| group, | ||
| activity_type, | ||
| data=activity_data if activity_data else None, |
There was a problem hiding this comment.
+1 ^^^
Also agree that having a referrer here would be nice.
| SentryAppEventType.SEER_CODING_COMPLETED, | ||
| SentryAppEventType.SEER_PR_CREATED, | ||
| SEER_EVENT_TO_ACTIVITY_TYPE: dict[SentryAppEventType, ActivityType] = { | ||
| SentryAppEventType.SEER_ROOT_CAUSE_STARTED: ActivityType.SEER_RCA_STARTED, |
There was a problem hiding this comment.
@kcons just a heads up on the naming -- easy enough to update these later, but wanted to give a heads up.
…ivity (#115525) Resolves [ID-1527](https://linear.app/getsentry/issue/ID-1527/update-the-issue-details-ui-to-support-display-of-new-seer-actions). Follow-up to #115486. Adds 7 new `GroupActivityType` enum values for Seer pipeline stages, to match the backend updates previously made in the above PR. These Seer actions are then rendered as part of issue activity in both the classic and streamlined issue detail views (using `IconSeer`). Gated behind an organization-level feature flag for initial rollout: `organizations:seer-activity-timeline`.
Resolves ID-1526 & ID-1525.
Adds 7 new members to the
ActivityTypeenum used for tracking issue activity, all corresponding to the possible webhook events Sentry can receive from Seer (link). These are (for now):The Sentry-side
process_autofix_updatestask runs when Seer webhook events are received, and this task also now createsActivityrecords for each of these event types.Gated behind an organization-level feature flag for initial rollout:
organizations:seer-activity-timeline.Will require a follow-up frontend PR to ensure that we are rendering these
Activitys correctly on the issue details page (#115525).