Skip to content

feat(issues): Record Seer events for display in the issue activity timeline#115486

Merged
shashjar merged 3 commits into
masterfrom
shashjar/add-seer-activity-types-to-issue-activity-timeline
May 13, 2026
Merged

feat(issues): Record Seer events for display in the issue activity timeline#115486
shashjar merged 3 commits into
masterfrom
shashjar/add-seer-activity-types-to-issue-activity-timeline

Conversation

@shashjar
Copy link
Copy Markdown
Member

@shashjar shashjar commented May 13, 2026

Resolves ID-1526 & ID-1525.

Adds 7 new members to the ActivityType enum used for tracking issue activity, all corresponding to the possible webhook events Sentry can receive from Seer (link). These are (for now):

  • RCA started
  • RCA completed
  • Solution started
  • Solution completed
  • Coding started
  • Coding completed
  • PR created

The Sentry-side process_autofix_updates task runs when Seer webhook events are received, and this task also now creates Activity records 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).

@github-actions github-actions Bot added the Scope: Backend Automatically applied to PRs that change backend components label May 13, 2026
# 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)
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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,
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Open to thoughts on exactly what metadata we want to include on the Activitys for each of these event types

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 ^^^

Also agree that having a referrer here would be nice.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@shashjar shashjar requested review from chromy, kcons and saponifi3d May 13, 2026 16:03
@shashjar shashjar marked this pull request as ready for review May 13, 2026 16:03
@shashjar shashjar requested review from a team as code owners May 13, 2026 16:03
@shashjar shashjar requested review from a team and removed request for a team May 13, 2026 16:03
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,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might want PR merged eventually but looks like we're generally missing the plumbing for that so it can come later.

Copy link
Copy Markdown
Contributor

@chromy chromy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, thanks!

Comment on lines +714 to +725
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"]
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean normalize the event payload Seer-side when the events get sent? I'm supportive of that - @chromy any thoughts?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, although i think we can reduce this down to 1 line of code per if statement w/o normalizing from seer.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+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,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kcons just a heads up on the naming -- easy enough to update these later, but wanted to give a heads up.

@linear-code
Copy link
Copy Markdown

linear-code Bot commented May 13, 2026

ID-1526

ID-1525

@shashjar shashjar merged commit 05d6f29 into master May 13, 2026
86 checks passed
@shashjar shashjar deleted the shashjar/add-seer-activity-types-to-issue-activity-timeline branch May 13, 2026 21:47
shashjar added a commit that referenced this pull request May 14, 2026
…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`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Scope: Backend Automatically applied to PRs that change backend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants