fix(autofix): Check preference repositories instead of tuning for Seer autofix onboarding check#112726
fix(autofix): Check preference repositories instead of tuning for Seer autofix onboarding check#112726
Conversation
…ofix_enabled Change is_autofix_enabled to check whether any project in the org has repositories configured in Seer preferences, rather than checking autofix_automation_tuning project options. Under the dual-read feature flag, query SeerProjectRepository directly. Otherwise, call the Seer API per active project and check preference.repositories. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
github-actions
bot
added
the
Scope: Backend
| .exists() | ||
| if features.has("organizations:seer-project-settings-read-from-sentry", organization): | ||
| return SeerProjectRepository.objects.filter( | ||
| project__organization_id=organization.id, project__status=ObjectStatus.ACTIVE |
There was a problem hiding this comment.
If repo is disabled/hidden its SeerProjectRepositoryRow will be deleted, so we don't need to filter by repo status here.
srest2021
changed the title
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| for project_id in project_ids: | ||
| try: | ||
| preference = get_project_seer_preferences(project_id).preference | ||
| if preference and preference.repositories: | ||
| return True | ||
| except (SeerApiError, SeerApiResponseValidationError): | ||
| pass | ||
|
|
||
| return False |
There was a problem hiding this comment.
Ahh, this is probably why we looked at ProjectOption before, because all the data in seer is a bigger hop to fetch.
Just for documentation sake, what's the current estimate on how long we'll have the two codepaths for seer-project-settings-read-from-sentry in here? like days, weeks, months?
There was a problem hiding this comment.
I want to finish up the read paths and start rolling out the flag next week. So probably for the next couple weeks!
And I forgot there is a bulk endpoint available 😭 Will be a quick fix and only one API call.
There was a problem hiding this comment.
a couple weeks isn't too bad at all. eligible users should make their first request to the endpoint on pageload, where speed of the endpoint won't really be visible, then when they get to an interactive area like Issue Details the response should be cached already.
![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.
Reviewed by Cursor Bugbot for commit 8c5d166. Configure here.
![sentry-warden[bot]](https://avatars.githubusercontent.com/in/2755838?s=60&v=4){kind=small}
… of false When the Seer API fails, return a 500 error instead of silently returning isAutofixEnabled=false. This prevents the frontend from caching a stale false value and showing incorrect "configure Seer" prompts on transient API failures.
2 participants
Change is_autofix_enabled to check whether any project in the org has repositories configured in Seer preferences, rather than checking autofix_automation_tuning project options.
Endpoint returns 500 if Seer API errors.