feat(seer): Add the stopping-point field to project-specific seer settings#112232
feat(seer): Add the stopping-point field to project-specific seer settings#112232
Conversation
github-actions
bot
added
the
Scope: Frontend
| getApiUrl(`/organizations/$organizationIdOrSlug/autofix/automation-settings/`, { | ||
| path: {organizationIdOrSlug: organization.slug}, | ||
| }), |
There was a problem hiding this comment.
This wasn't staying up to date with the actual queryKey in use. We're fetching infinite data, so things would've never matched here.
Requiring the proper ApiQueryKey type for invalidateQueries is something i want to followup on across the whole codebase, that should encourage more use of apiOptions and similar
There was a problem hiding this comment.
if we switch to queryOptions this should be implicitly lint-able with:
https://tanstack.com/query/v5/docs/eslint/prefer-query-options
| organization, | ||
| }); | ||
| queryClient.invalidateQueries({ | ||
| queryKey: [`/organizations/${organization.slug}/autofix/automation-settings/`], |
There was a problem hiding this comment.
again, wrong query key. People ideally shouldn't be doing string-interpolation for api urls anymore.
| export function getProjectStoppingPointValue( | ||
| project: Project, | ||
| preference: ProjectSeerPreferences | ||
| ): SelectValue { | ||
| if ([null, undefined, 'off'].includes(project.autofixAutomationTuning)) { | ||
| return 'off'; | ||
| } | ||
| return preference.automated_run_stopping_point === 'root_cause' ? 'root_cause' : 'code'; | ||
| } | ||
|
|
There was a problem hiding this comment.
same logic as getDefaultStoppingPointValue above, just with different field names
having the names align is a goal as we update the endpoints, but not for this PR :(
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
static/app/views/settings/seer/overview/utils/seerStoppingPoint.ts
Outdated
Show resolved
Hide resolved
![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 b840624. Configure here.
static/app/views/settings/seer/overview/utils/seerStoppingPoint.ts
Outdated
Show resolved
Hide resolved
…eference field The onSuccess handler was spreading the entire SeerPreferencesResponse object (which contains code_mapping_repos and preference) directly into the preference field. The preference field expects ProjectSeerPreferences (repositories, automated_run_stopping_point, automation_handoff), so this created a malformed cache entry with a nested preference key and a misplaced code_mapping_repos field. Fix by spreading preferencePayload.preference instead of preferencePayload. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
| setApiQueryData<SeerPreferencesResponse>(queryClient, seerPrefsQueryKey, { | ||
| ...previous, | ||
| preference: { | ||
| repositories: [], |
There was a problem hiding this comment.
Bug: The optimistic cache update in onSuccess spreads preferencePayload.preference without guarding against null or undefined, leading to an incomplete cache update and stale UI data.
Severity: MEDIUM
Suggested Fix
Guard against null or undefined values before spreading preferencePayload.preference. For example, use the nullish coalescing operator: ...(preferencePayload.preference ?? {}).
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: static/app/views/settings/seer/overview/utils/seerStoppingPoint.ts#L192
Potential issue: In the `onSuccess` handler for a mutation, the code updates the cache
optimistically by spreading `preferencePayload.preference`. However, the type for this
property allows it to be `null` or `undefined`. When a `null` or `undefined` value is
received from the API, spreading it is a no-op in JavaScript. This causes the new
`automated_run_stopping_point` value to be omitted from the cache update, resulting in a
silent data corruption. The UI will then display stale data until a forced refetch
occurs, which can cause a visual flicker.
…tings (#112232) This brings in the stopping-point dropdown to the project-specific seer settings page Follows: #112211 There's still more to cleanup in here, but we're well on the way. <img width="960" height="383" alt="SCR-20260403-msjw" src="https://github.com/user-attachments/assets/09b86dd8-6a0e-4bf5-89d9-9cd9d9649f6d" /> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
2 participants
This brings in the stopping-point dropdown to the project-specific seer settings page
Follows: #112211
There's still more to cleanup in here, but we're well on the way.