-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
feat(code-review): Handle issue comment incl eyes emoji #105527
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
base: master
Are you sure you want to change the base?
Conversation
armenzg
left a comment
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.
I'm sending some feedback for now. I need to implement something and get back to you.
| comment_id: str, | ||
| ) -> None: | ||
| if integration is None: | ||
| metrics.incr("seer.code_review.webhook.issue_comment.reaction_missing_integration") |
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.
I tend to use a prefix so I can easily create error widgets in Datadog.
sentry/src/sentry/seer/code_review/webhooks/check_run.py
Lines 44 to 45 in 40560ae
| class Metrics(enum.StrEnum): | |
| ERROR = "seer.code_review.error" |
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.
This is really nice. Thanks for the best practice.
Should it be scoped this widely as all of seer.code_review.error, or worth narrowing down the ones I added to seer.code_review_.webhook.issue_comment.error?
| client = integration.get_installation(organization_id=organization.id).get_client() | ||
| client.create_comment_reaction(repo.name, comment_id, GitHubReaction.EYES) | ||
| metrics.incr("seer.code_review.webhook.issue_comment.reaction_added") | ||
| except Exception: |
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.
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.
On this one, I was purposely having the helper _add_eyes_reaction_to_comment log and swallow the exception so every caller of the helper wouldn't need to wrap in a try/catch. I would like us to still forward to seer even if for some reason the 👀 posting failed. For example if we hit a rate limit here, but still want the PR review itself to proceed. What do you think?
| } | ||
|
|
||
| def _enable_code_review(self) -> None: | ||
| self.organization.update_option("sentry:enable_pr_review_test_generation", True) |
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.
Since we're adding new code, would it make sense to open a PR to add a more meaningful option? That way we can remediate the problem as we're making progress in the Overwatch port. I now see why you asked me about that other ticket.
It's possible this is way more complicated than I assume 😆 .
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.
Yeah.. I'll clean this up with https://linear.app/getsentry/issue/CW-88/list-features-and-related-features-for-code-review
| mock_forward.assert_not_called() | ||
|
|
||
| @patch("sentry.seer.code_review.webhooks.issue_comment._add_eyes_reaction_to_comment") | ||
| @patch("sentry.seer.code_review.webhooks.handlers._forward_to_seer") |
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.
For this case, instead of mocking the task scheduling remove this and use with self.tasks():
You will need to mock the function that would attempt to do the reaction.
I like to see closer to full integration testing when dealing with the success case.
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.
updated!
armenzg
left a comment
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.
This is very close. A few more changes and we can merge it.
| mock_integration, self.organization, self.repo, "123456789" | ||
| ) | ||
| mock_create_reaction.assert_called_once() | ||
| mock_seer.assert_called_once() |
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.
@suejung-sentry Calling Seer should not happen since we have not set the option to False (Switching from forwarding to Overwatch to Seer).
There's a bug in this code which I was going to handle in one of my PRs:
| make_seer_request(path=SeerEndpoint.SENTRY_REQUEST.value, payload=event_payload) |
I will be adding a way to prevent the call to Seer if the options for the specific Github event type is not set to False.
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.
Thanks, I totally thought we were flipping the other way around, my bad. I'll await your other PR that makes the fix and you can make any changes to this PR as we discussed
| if comment_id: | ||
| if not options.get("github.webhook.issue-comment"): | ||
| _add_eyes_reaction_to_comment(integration, organization, repo, str(comment_id)) | ||
|
|
||
| # Import here to avoid circular dependency with handlers | ||
| from .handlers import _schedule_task | ||
|
|
||
| _schedule_task(event_type, event, organization, repo) |
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 _schedule_task function is called unconditionally, causing duplicate processing when the github.webhook.issue-comment option is True.
Severity: HIGH | Confidence: High
🔍 Detailed Analysis
In issue_comment.py, the code checks the github.webhook.issue-comment option. If this option is False, it adds a reaction. However, the call to _schedule_task on line 114 occurs outside of this conditional check, meaning it is executed unconditionally. This causes a task to be scheduled in Sentry even when the option is True, a state intended to forward the event to another service (Overwatch). This results in the event being processed by both Sentry and the other service, leading to conflicting behavior.
💡 Suggested Fix
Move the _schedule_task(...) call inside the if not options.get("github.webhook.issue-comment"): block to ensure it is only executed when this option is False.
🤖 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/seer/code_review/webhooks/issue_comment.py#L107-L114
Potential issue: In `issue_comment.py`, the code checks the
`github.webhook.issue-comment` option. If this option is `False`, it adds a reaction.
However, the call to `_schedule_task` on line 114 occurs outside of this conditional
check, meaning it is executed unconditionally. This causes a task to be scheduled in
Sentry even when the option is `True`, a state intended to forward the event to another
service (Overwatch). This results in the event being processed by both Sentry and the
other service, leading to conflicting behavior.
Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 8054017

Hook up so we handle issue comment including the posting of eyes emoji from within sentry. This is behind an option for
github.webhook.issue-commentwhich decides whether we route flow through this path or the path that forwards to overwatch.Note that though in theory overwatch at some point also supported review (including posting 👀 ) for pull_request_review and pull_request_review_comment, I tried out these flows and they don't need to be working right now. I think it's fine to maintain parity and just port it over as just the issue comment is how you can trigger the on_command_phrase review.
Closes CW-10