feat(discover): add endpoint for single saved query updates - #123926
Conversation
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.
Reviewed by Cursor Bugbot for commit aa721e2. Configure here.
nikkikapadia
left a comment
There was a problem hiding this comment.
lgtm just some comments on cursor's comments
| try: | ||
| query = DiscoverSavedQuery.objects.get( | ||
| Q(is_homepage=False) | Q(is_homepage__isnull=True), id=id, organization=organization | ||
| ) | ||
| except DiscoverSavedQuery.DoesNotExist: |
There was a problem hiding this comment.
Bug: The position field is accepted by the StarQuerySerializer but is silently ignored by the endpoint, which always appends the starred query to the end.
Severity: MEDIUM
Suggested Fix
Modify the endpoint to read the position value from the validated serializer data. Update DiscoverSavedQueryStarredManager.insert_starred_query to accept an optional position parameter. If a position is provided, use it to insert the starred query at the specified location instead of always appending it.
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/discover/endpoints/discover_saved_query_starred.py#L66-L70
Potential issue: The `StarQuerySerializer` accepts an optional `position` field, but the
endpoint logic silently ignores it. The code only reads the `is_starred` value from the
validated serializer data and never extracts or uses the `position`. The call to
`DiscoverSavedQueryStarredManager.insert_starred_query` does not pass a position;
instead, the underlying method always calculates a new position by calling
`next_starred_position`. This results in any client-provided `position` being
disregarded, and the starred query is always appended to the end of the list, leading to
unexpected ordering behavior.
There was a problem hiding this comment.
Not an issue because clients arent ordering the queries on creation, it's done automatically by insert_starred_query

Changes
Address part of EXP-1166 in effort to port the remaining discover queries to explore all queries. This PR adds: