feat(explorer): Add get_issue_details and get_event_details RPCs#110027
feat(explorer): Add get_issue_details and get_event_details RPCs#110027
Conversation
github-actions
bot
added
the
Scope: Backend
aliu39
changed the title
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
There was a problem hiding this comment.
Feels like there should be some kind of consolidation here so the organization_seer_rpc and seer_rpc stay in sync
There was a problem hiding this comment.
I think the reason for keeping them separate was in case we didnt want to expose some rpc in this endpoint. but agree it's usually inconvenient/a common gotcha
| try: | ||
| activities = Activity.objects.filter( | ||
| group=group, | ||
| type__in=_SEER_EXPLORER_ACTIVITY_TYPES, | ||
| ).order_by("-datetime")[:50] | ||
| serialized_activities = serialize( | ||
| list(activities), user=None, serializer=ActivitySerializer() | ||
| ) | ||
| except Exception: | ||
| logger.exception( | ||
| "get_issue_details: Failed to get user activity", | ||
| extra={"organization_id": organization_id, "issue_id": issue_id}, | ||
| ) | ||
| serialized_activities = [] |
There was a problem hiding this comment.
What's the reason for including user activities? Have you seen it be useful in practice before? I know I personally almost never look at it outside of a retro scenario where I'm collecting timestamps of when things happened.
There was a problem hiding this comment.
It's useful context if teammates have commented or changed status in the past, also auto sentry actions like marked as regression, assigned by a rule..
Co-authored-by: Tony Xiao <txiao@sentry.io>
Co-authored-by: Tony Xiao <txiao@sentry.io>
2 participants
Add two focused RPCs to the Seer Explorer tool layer by splitting the responsibilities of
get_issue_and_event_details_v2:get_issue_details(organization_id, issue_id, start?, end?, project_slug?)Returns issue-level data for a given issue: serialized group metadata (title, status, assignee, priority, etc.), event count timeseries, tags overview, and user activity. Accepts either a numeric group ID or a qualified short ID (e.g.
PROJECT-123).get_event_details(organization_id, event_id?, issue_id?, start?, end?, project_slug?)Returns a single serialized event. Accepts either a direct
event_idor anissue_id(mutually exclusive), in which case it fetches the recommended event for the group within the given time range.Both are registered as RPCs in
seer_rpc.pyandorganization_seer_rpc.pyalongside the existingget_issue_and_event_details_v2, which remains unchanged.The split allows callers to fetch only the data they need — issue metadata and event data are often needed independently, and combining them in one call was unnecessarily expensive.