-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
feat(autopilot): Missing SDK integration detector #105595
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(autopilot): Missing SDK integration detector #105595
Conversation
| def run_missing_sdk_integration_detector() -> None: | ||
| organization_allowlist = options.get("autopilot.organization-allowlist") | ||
| if not organization_allowlist: | ||
| return | ||
|
|
||
| organizations = Organization.objects.filter(slug__in=organization_allowlist).all() | ||
|
|
||
| for organization in organizations: | ||
| run_missing_sdk_integration_detector_for_organization(organization) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: The run_missing_sdk_integration_detector task can time out because its sequential, blocking calls per project can easily exceed the overall task deadline of 300 seconds.
Severity: CRITICAL | Confidence: High
🔍 Detailed Analysis
The task run_missing_sdk_integration_detector has a hard processing deadline of 300 seconds. Within this task, it iterates through an organization's projects sequentially. For each project, it makes a blocking call, client.get_run(..., blocking=True, poll_timeout=120.0), which can wait for up to 120 seconds. For an organization with three or more projects, the cumulative wait time (e.g., 3 projects * 120s = 360s) will exceed the task's 300-second deadline. This causes the task worker to forcefully terminate the process, resulting in an unexpected crash and incomplete execution for the organization.
💡 Suggested Fix
Refactor the task to avoid accumulating long, blocking waits in a single process. Consider processing projects in parallel using subtasks or using non-blocking calls to the client.get_run method to prevent the main task from exceeding its deadline.
🤖 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/autopilot/tasks.py#L156-L164
Potential issue: The task `run_missing_sdk_integration_detector` has a hard processing
deadline of 300 seconds. Within this task, it iterates through an organization's
projects sequentially. For each project, it makes a blocking call, `client.get_run(...,
blocking=True, poll_timeout=120.0)`, which can wait for up to 120 seconds. For an
organization with three or more projects, the cumulative wait time (e.g., 3 projects *
120s = 360s) will exceed the task's 300-second deadline. This causes the task worker to
forcefully terminate the process, resulting in an unexpected crash and incomplete
execution for the organization.
Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 8099400
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not a concern at the moment, as this is PoC phase on the org with a couple of projects, but good call out by bot
|
|
||
| # Get docs URL from platform data | ||
| platform_data = INTEGRATION_ID_TO_PLATFORM_DATA.get(project.platform or "", {}) | ||
| docs_url = platform_data.get("link", "https://docs.sentry.io/platforms/") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Platform data lookup uses wrong dictionary key type
The lookup INTEGRATION_ID_TO_PLATFORM_DATA.get(project.platform or "", {}) uses project.platform values (like "django", "flask", "react") directly as keys, but INTEGRATION_ID_TO_PLATFORM_DATA is keyed by integration IDs (like "python-django", "javascript-react"). Many platform values need to be mapped via MARKETING_SLUG_TO_INTEGRATION_ID first to get the correct integration ID. This causes the lookup to fail for many platforms, silently falling back to the generic docs URL instead of platform-specific documentation. The warning-level logging with debug info suggests this issue was already being investigated.
| Refer to the Sentry SDK integrations documentation for available integrations: | ||
| {docs_url} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just curious, is there no tool already built in that can read the docs if the platform is known, do we have to pass the URL?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not afaik
Add a detector for missing SDK integrations that utilizes the SeerExplorerClient.