feat(triage signals): Seer orgs on new pricing need to have Github integration to use autofix

[Mihir-Mavalankar]

PR Details

• We were going to make Seer require the GitHub connection going forward with the new pricing.
• This PR adds check in the new automation flow only if github repos are not connected.
• More context in thread: https://sentry.slack.com/archives/C09QCAEA0DR/p1764963646314459

[Mihir-Mavalankar]

@roaga I'm unsure if this is the right way to stop it in the UI. lmk what you think.

[roaga]

i don't think we're requiring code mappings, only github integration

[Mihir-Mavalankar]

i don't think we're requiring code mappings, only github integration

Okay so that is already checked in the issue details UI right? So i can leave that unchanged.

And in kickoff_seer_automation should I just use get_autofix_integration_setup_problems just to check that the project has github integration?

[Mihir-Mavalankar]

Actually get_autofix_integration_setup_problems checks the org level integration not project level so I can't use that. The org could have the integration but that specific project might not.
Code mapping might be best for project level. Is there any catch/drawback with them?

[roaga]

Actually get_autofix_integration_setup_problems checks the org level integration not project level so I can't use that. The org could have the integration but that specific project might not. Code mapping might be best for project level. Is there any catch/drawback with them?

@Mihir-Mavalankar code mappings are an extra thing people can configure but are an extra piece of work on top of a plain GitHub integration.

If your goal is to stop Autofix from running automation on a project without connected repos, you should check that the project has either code mappings or repos connected via seer project preferences.

To stop it in the UI, you need to do frontend work as Autofix is currently allowed to run without repo connections. It will currently only show a warning at the top.

[Mihir-Mavalankar]

Actually get_autofix_integration_setup_problems checks the org level integration not project level so I can't use that. The org could have the integration but that specific project might not. Code mapping might be best for project level. Is there any catch/drawback with them?

@Mihir-Mavalankar code mappings are an extra thing people can configure but are an extra piece of work on top of a plain GitHub integration.

If your goal is to stop Autofix from running automation on a project without connected repos, you should check that the project has either code mappings or repos connected via seer project preferences.

To stop it in the UI, you need to do frontend work as Autofix is currently allowed to run without repo connections. It will currently only show a warning at the top.

Okay so the backend check is fine since it checks for code mapping via get_autofix_repos_from_project_code_mappings?
And I just need to change the frontend check? Or maybe I can remove it for now and add to a later PR?

[roaga]

Actually get_autofix_integration_setup_problems checks the org level integration not project level so I can't use that. The org could have the integration but that specific project might not. Code mapping might be best for project level. Is there any catch/drawback with them?

@Mihir-Mavalankar code mappings are an extra thing people can configure but are an extra piece of work on top of a plain GitHub integration.
If your goal is to stop Autofix from running automation on a project without connected repos, you should check that the project has either code mappings or repos connected via seer project preferences.
To stop it in the UI, you need to do frontend work as Autofix is currently allowed to run without repo connections. It will currently only show a warning at the top.

Okay so the backend check is fine since it checks for code mapping via get_autofix_repos_from_project_code_mappings? And I just need to change the frontend check? Or maybe I can remove it for now and add to a later PR?

if you're trying to block autofix runs without github integration, the existing check won't do that. The current function to get code mappings is just optional extra data we send to seer

[Mihir-Mavalankar]

Actually get_autofix_integration_setup_problems checks the org level integration not project level so I can't use that. The org could have the integration but that specific project might not. Code mapping might be best for project level. Is there any catch/drawback with them?

@Mihir-Mavalankar code mappings are an extra thing people can configure but are an extra piece of work on top of a plain GitHub integration.
If your goal is to stop Autofix from running automation on a project without connected repos, you should check that the project has either code mappings or repos connected via seer project preferences.
To stop it in the UI, you need to do frontend work as Autofix is currently allowed to run without repo connections. It will currently only show a warning at the top.

Okay so the backend check is fine since it checks for code mapping via get_autofix_repos_from_project_code_mappings? And I just need to change the frontend check? Or maybe I can remove it for now and add to a later PR?

if you're trying to block autofix runs without github integration, the existing check won't do that. The current function to get code mappings is just optional extra data we send to seer

@roaga so is the only way to check that to call the project preference api in Seer and and check if there is a list of projects?

[cursor]

Bug: API failure after cache lock causes missed automation

The has_project_connected_repos check is placed after cache.add(automation_dispatch_cache_key, ...) on line 1688, which atomically blocks duplicate dispatches. If the Seer API call in has_project_connected_repos raises a SeerApiError (as the test test_raises_on_api_error confirms it can), the exception propagates but the cache key remains set for 5 minutes. This blocks any subsequent automation dispatch attempts for that group, even though no automation was actually dispatched. The repo check should happen before the cache lock to avoid this scenario.

 

[Mihir-Mavalankar]

The risk is acceptable IMO. Keeping outside the lock means a lot more volume to the API endpoint which we want to avoid.
If it fails because of an API error automation will be re-tried after 5 minutes when new events come.

[roaga]

if the user doesn't have repos connected, automation is not running. Then let's say they set up the repos. Doesn't that mean we won't run automation for a whole hour until the cache expires? Is that acceptable?

[Mihir-Mavalankar]

if the user doesn't have repos connected, automation is not running. Then let's say they set up the repos. Doesn't that mean we won't run automation for a whole hour until the cache expires? Is that acceptable?

Yes. There is a chance that they add repos in that hour but yes, till the cache expires yes. Otherwise we need to find a new way to check if projects have connected repos because calling an endpoint everytime is expensive.