feat(codegen): increment org contributors and assign seat in PR webhook handler

[srest2021]

fixes ENG-5935

depends on #104371

Track an active contributor on a PR event webhook, if the repo has Seer and AI features enabled (and the seat-based-seer-enabled feature flag)

• Increment the contributor's num actions.
• Only assign a seat to the contributor if it is not a bot or an external contributor.
• Assign a seat to a contributor on/after the second PR event (not the first)--ticket to optimize this here.
• Seat assignment occurs in a task for robustness. We log a warning if it fails. We plan to add a retry once we know more about each non-ACCEPTED billing outcome and its frequency.

Extra notes

Info about the user's type (ie, bot or not) and association (ie, external contributor or not) can be obtained from the webhook payload, per the gh docs and gh enterprise docs.

• payload["pull_request"]["author_association"] is a required field for all pull_request, pull_request_review, and pull_request_review_comment action types, and also in gh enterprise. ✅ -> Added to all gh and gh enterprise fixtures.
• payload["pull_request"]["user"]["type"] is required for the pull_request.opened and pull_request.closed action types. ✅
• payload["pull_request"]["user"]["type"] is not required for pull_request.edited, or any pull_request_review or pull_request_review_comment action types. But I set up a gh app and triggered pull_request.edited and pull_request_review.submitted webhooks and the field was indeed present. It's also already present in the fixtures used in the tests. I'm assuming we can expect it for the majority of webhooks, unless the user somehow hasn't been "classified" already (?). If we can't find the user type we just assume the user isn't a bot (feedback welcome on this behavior).

[linear]

ENG-5942 Create Cron for Resetting ActiveContributors when Product Trial Ends

ENG-5935 Instrument Seer Event Requested Endpoint

[codecov]

❌ 1 Tests Failed:

Tests completed	Failed	Passed	Skipped
29283	1	29282	234

View the top 1 failed test(s) by shortest run time

tests.sentry.integrations.github.test_utils.ShouldCreateOrIncrementContributorSeatTest::test_returns_false_when_seat_based_seer_disabled

Stack Traces | 2.5s run time

#x1B[1m#x1B[.../hostedtoolcache/Python/3.13.1........./x64/lib/python3.13/unittest/case.py#x1B[0m:58: in testPartExecutor
    yield
#x1B[1m#x1B[.../hostedtoolcache/Python/3.13.1........./x64/lib/python3.13/unittest/case.py#x1B[0m:651: in run
    self._callTestMethod(testMethod)
#x1B[1m#x1B[.../hostedtoolcache/Python/3.13.1........./x64/lib/python3.13/unittest/case.py#x1B[0m:606: in _callTestMethod
    if method() is not None:
#x1B[1m#x1B[31mE   TypeError: ShouldCreateOrIncrementContributorSeatTest.test_returns_false_when_seat_based_seer_disabled() missing 1 required positional argument: 'mock_quota'#x1B[0m

To view more test analytics, go to the Test Analytics Dashboard
_{📋 Got 3 mins? Take this short survey to help us improve Test Analytics.}

[ajay-sentry]

is this in addition to the 3 retries we get? I'm thinking that might be enough potentially. Where if we fail those 3 retries we could do a reconciliation thing later on (and since it's all in a transaction anyway, num_actions also wouldn't increment)

[ajay-sentry]

By "all being in a transaction" I mean the original task firing along with the num_actions increment

[srest2021]

I believe it does count towards the 3 retries. I can increase to 5 retries no prob. What sort of reconciliation were you thinking of doing?

[srest2021]

Update after syncing in person: removing retry_task altogether. We'll use the logs to see what kinds of outcomes are common/flaky/worth retrying, and add it in once we have a better idea of which outcomes it's helpful to retry on.

[cursor]

Bug: date_updated not updated when incrementing num_actions

The contributor.save(update_fields=["num_actions"]) call won't update the date_updated field even though it has auto_now=True. Django's auto_now behavior doesn't apply when update_fields is specified and the field isn't included in the list. This means the date_updated timestamp will remain stale after num_actions is incremented. There's an index on ["organization_id", "date_updated"] suggesting this field is used for queries, and the reset_num_actions_for_organization_contributors task correctly handles this by explicitly setting date_updated=timezone.now().

 

[srest2021]

I removed it but just put it back @ajay-sentry, it looks like it's a common pattern to include date_updated in update_fields (removed the manual contributor.date_updated = django_timezone.now() though as it looks like that's not needed)

Examples 1, 2, 3, 4

[ajay-sentry]

lgtm, @brendanhsentry that's the right flag, right?