ref(ai-monitoring): Align list titles with detail selection - #121053
ref(ai-monitoring): Align list titles with detail selection#121053vgrozdanic wants to merge 2 commits into
Conversation
Pick one title per conversation by earliest title_source_timestamp (project_id on ties), and keep the list endpoint up if metadata lookup fails.
github-actions
Bot
added
the
Scope: Backend
Conversation ids are only unique within a project, so bulk title lookup returns per (conversation_id, project_id) again. List still picks a stable display title and survives metadata lookup failures.
![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 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 87c8f81. Configure here.
| extra={"project_ids": sorted({project_id for _, project_id in pairs})}, | ||
| ) | ||
| return | ||
|
|
There was a problem hiding this comment.
List title selection still misaligned
Medium Severity
The list path still resolves titles through _first_title, which picks the lowest project_id with a stored title. Detail uses TITLE_ORDER_BY (title_source_timestamp, then project_id), so multi-project conversations can still show different titles on list vs detail.
Additional Locations (2)
Reviewed by Cursor Bugbot for commit 87c8f81. Configure here.
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| titles: dict[tuple[str, int], str] = {} | ||
| for row_hash, project_id, title in rows: | ||
| pair = (conversation_id_by_hash[row_hash], project_id) | ||
| if title and pair in requested_pairs: | ||
| if pair in requested_pairs: |
There was a problem hiding this comment.
Bug: The conversation list view incorrectly picks a title by lowest project_id, while the detail view uses the earliest title_source_timestamp, causing title inconsistency between views.
Severity: MEDIUM
Suggested Fix
Update the list view's data fetching logic, specifically fetch_conversation_titles(), to order results by title_source_timestamp and then project_id. This will align its title selection mechanism with the detail view's fetch_conversation_title() and ensure both views display the same title consistently.
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/ai_monitoring/utils.py#L146-L149
Potential issue: The logic for selecting an AI conversation title is inconsistent
between the list and detail views. The detail view correctly selects the title based on
the earliest `title_source_timestamp`, with `project_id` as a tie-breaker. However, the
list view's implementation in `_first_title()` incorrectly selects the title based on
the lowest `project_id`, ignoring the timestamp. This will cause users to see different
titles for the same conversation in the list view versus the detail view if the project
with the earliest title timestamp is not also the one with the lowest project ID.
Also affects:
src/sentry/api/endpoints/organization_ai_conversations.py:592~618
Did we get this right? 👍 / 👎 to inform future reviews.
2 participants
List and detail now resolve the same stored title for a multi-project conversation: the one closest to the first user message (
title_source_timestamp), withproject_idonly breaking ties. Previously the list preferred the lowest project id that had any title, so the two surfaces could disagree.Title metadata lookup failures no longer fail the conversations list; titles stay unset and the rest of the payload still returns.