feat(integrations): Add GitHub Copilot polling functionality#106670
feat(integrations): Add GitHub Copilot polling functionality#106670
Conversation
Add backend support for GitHub Copilot as a coding agent provider for Autofix: - New GitHub Copilot client using Tasks API - Integration and identity service for Copilot auth - Update coding agent endpoint to support Copilot provider - Feature flag for GitHub Copilot integration
- Remove redundant variable assignment in _validate_and_get_integration - Use .get() for safer dict access in repo extraction functions - Simplify PR artifact lookup using next() instead of manual loop - Add explicit parentheses to tuple return for clarity
GitHub Copilot doesn't need an org-wide integration since it uses per-user OAuth tokens. Use the client directly instead of going through an integration wrapper class.
Slim down the PR by removing the poll_github_copilot_agents function and related models. This can be added back in a follow-up PR.
Make the function more extensible for future user-based providers by accepting a CodingAgentClient instance instead of hardcoding GitHub Copilot. The caller now creates the appropriate client.
…pilot identity Allow getsentry to override the GitHubCopilotIdentityService implementation via the GITHUB_COPILOT_IDENTITY_SERVICE setting. This follows the same pattern as SENTRY_QUOTAS for cross-repo service overrides. Also add feature flag check to the coding agents POST endpoint. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…tion tests - Rename feature flag from `organizations:integrations-github-copilot` to `organizations:integrations-github-copilot-agent` - Add test for providing both integration_id and provider (validation error) - Add test for invalid provider when GitHub Copilot feature is disabled - Remove redundant feature check from POST endpoint (already checked in launch_coding_agents_for_run) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Move the default implementation inline to service.py. When no GITHUB_COPILOT_IDENTITY_SERVICE setting is configured, return None directly instead of using a separate impl.py file. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add ability to poll GitHub Copilot agents for status updates and PR creation. This enables tracking the progress of GitHub Copilot coding agents and updating autofix state when PRs are created.
github-actions
bot
added
the
Scope: Backend
|
@sentry review |
|
bugbot review |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| logger.info( | ||
| "coding_agent.github_copilot.task_failed", | ||
| extra={"agent_id": agent_id, "task_status": task_status.status}, | ||
| ) |
There was a problem hiding this comment.
Completed tasks without PR artifact stay stuck in RUNNING
Medium Severity
The polling logic doesn't handle the case where a task completes without creating a PR artifact, or when a PR artifact exists but get_pr_from_graphql returns None. In these scenarios, the elif task_status.status in ("failed", "error") condition is not met (since the status is "completed" or "succeeded"), so nothing happens and the agent remains in RUNNING status indefinitely. A completed task should transition to a terminal state (COMPLETED or FAILED) rather than staying in RUNNING.
Additional Locations (1)
There was a problem hiding this comment.
in my experience with the API this doesn't happen.
|
|
||
| # TODO: poll GitHub Copilot agents for status updates | ||
| if autofix_state and autofix_state.coding_agents and request.user.id: | ||
| poll_github_copilot_agents(autofix_state, user_id=request.user.id) |
There was a problem hiding this comment.
Response returns stale state after polling discovers updates
Low Severity
The polling function discovers PR updates and writes them to Seer via update_coding_agent_state, but the response is built from the original autofix_state fetched before polling. When a PR is discovered during polling, the user won't see it in the current response - they'll only see it on their next GET request. This creates confusing behavior where the system knows about updates but doesn't include them in the response.
Additional Locations (1)
There was a problem hiding this comment.
that's fine, we refresh very frequently
There was a problem hiding this comment.
Is the expectation here that the frontend continuously polls? I know right now the frontend still polls even though the run status is complete, in which case, this is okay. But if we ever decide to stop polling on the frontend when the run status is complete, isn't it possible that we never return the PR?
There was a problem hiding this comment.
in practice i think this will be very rare, if not impossible, because the way in which copilot works is that it will create the PR immediately upon running, then as it iterates it refreshes the PR description as its way of showing its progress. so by the time the run status is complete, we'll have already linked the PR.
2 participants
This PR:
decode_agent_id,get_task_status, andget_pr_from_graphqlmethods to clientpoll_github_copilot_agentsfunction to update autofix state when PRs are created