Skip to content

feat: create barebones sentry webhook endpoint #59

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

joseph-sentry
Copy link
Contributor

@joseph-sentry joseph-sentry commented Apr 25, 2025

This endpoint will be called by the webhook forwarding code in Sentry.

We're using the existing Sentry -> Codecov communication method where
we validate that the request is indeed coming from Sentry to
authenticate. So the Sentry is using the CodecovApiClient to make the
request and we're using the JWTAuthenticationPermission here.

We could have implemented this as part of the existing Github webhook
endpoint but that would've made its implementation more complicated so
I made the choice to have another endpoint that handles post requests
separately but still uses the Github endpoint's functionality for
processing webhooks.

For now, I want to "dry run" processing the webhooks here, which is
why I wrap the handling of webhooks around a transaction. This might
be a bad idea if we're going to have conflicting writes to similar
rows, which is a possibility with handling webhooks.

I've checked that the push and pull_request webhooks make their writes
to the db at the end of the handling. I think it should be unlikely we
often get conflicting writes for the installation webhooks.

In that case it might be worth it to rewrite the webhook handlers to
allow "dry_run" variants where no writes are actually made.

We must also consider cases where a User has installed both the Sentry
app and the Codecov app, which could be a common case, we should only
handle webhooks that we receive from Sentry in that case, so we'll
have to add some bookkeeping for that, but that's for the future, when
the Sentry webhook handler will be responsible for writing.


I added a feature flag to toggle the "dry runs" in general, we check against a
constant number because it's likely we'll want to either toggle this on or off
completely and we don't have guaranteed access to repoids or ownerids.

@codecov-notifications
Copy link

codecov-notifications bot commented Apr 25, 2025

Codecov Report

Attention: Patch coverage is 95.74468% with 2 lines in your changes missing coverage. Please review.

✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
apps/codecov-api/webhook_handlers/views/sentry.py 94.87% 2 Missing ⚠️

📢 Thoughts on this report? Let us know!

Copy link

codecov bot commented Apr 25, 2025

Codecov Report

Attention: Patch coverage is 95.74468% with 2 lines in your changes missing coverage. Please review.

Project coverage is 94.34%. Comparing base (b24e2e8) to head (1a7a243).

✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
apps/codecov-api/webhook_handlers/views/sentry.py 94.87% 2 Missing ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #59   +/-   ##
=======================================
  Coverage   94.34%   94.34%           
=======================================
  Files        1223     1224    +1     
  Lines       45305    45346   +41     
  Branches     1441     1441           
=======================================
+ Hits        42744    42783   +39     
- Misses       2260     2262    +2     
  Partials      301      301           
Flag Coverage Δ
apiunit 96.47% <95.74%> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@joseph-sentry joseph-sentry requested a review from a team May 28, 2025 16:51
@joseph-sentry joseph-sentry marked this pull request as ready for review May 28, 2025 17:37
Comment on lines 23 to 29
with transaction.atomic():
# this looks weird but we're basically doing "dry runs"
# of the webhook handling

# this will eventually be removed once we validate it's working
# correctly in prod
transaction.set_rollback(True)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lets hope the assumption that we can use transaction rollback for this actually works out, lol

This endpoint will be called by the webhook forwarding code in Sentry.

We're using the existing Sentry -> Codecov communication method where
we validate that the request is indeed coming from Sentry to
authenticate. So the Sentry is using the CodecovApiClient to make the
request and we're using the JWTAuthenticationPermission here.

We could have implemented this as part of the existing Github webhook
endpoint but that would've made its implementation more complicated so
I made the choice to have another endpoint that handles post requests
separately but still uses the Github endpoint's functionality for
processing webhooks.

For now, I want to "dry run" processing the webhooks here, which is
why I wrap the handling of webhooks around a transaction. This might
be a bad idea if we're going to have conflicting writes to similar
rows, which is a possibility with handling webhooks.

I've checked that the push and pull_request webhooks make their writes
to the db at the end of the handling. I think it should be unlikely we
often get conflicting writes for the installation webhooks.

In that case it might be worth it to rewrite the webhook handlers to
allow "dry_run" variants where no writes are actually made.

We must also consider cases where a User has installed both the Sentry
app and the Codecov app, which could be a common case, we should only
handle webhooks that we receive from Sentry in that case, so we'll
have to add some bookkeeping for that, but that's for the future, when
the Sentry webhook handler will be responsible for writing.
- Refactored the installation handling logic to dynamically call the appropriate method based on the event type.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants