handlePullRequest() returns [] immediately unless payload.action === 'closed' && payload.pull_request.merged — i.e. it does nothing at all for a PR-opened (or reopened, synchronize, etc.) webhook event. BountiesService.markInReview(id, prUrl, prNumber) exists specifically to transition a bounty CLAIMED -> IN_REVIEW when a PR is opened against its issue, but the only place it's ever called is inside handlePullRequest's merged-PR branch, immediately before markMergedAndRelease — i.e. markInReview only ever fires in the same instant as a merge, never in response to the actual "a PR was opened" event that should trigger it.
Practical consequence: a contributor who opens a PR that sits open for review (the common case) never sees their bounty move to IN_REVIEW from the webhook's perspective — it stays CLAIMED in the database (and in any UI reading Bounty.status) right up until the PR is merged, at which point IN_REVIEW and MERGED both happen within the same request. This is distinct from the already-filed issue about a PR closed without merging having no handler — this is about PRs that are opened (merged or not) having no handler either. Add a case for action === 'opened' (and arguably 'reopened') that resolves the linked bounty and calls markInReview at the time the PR is actually opened.
handlePullRequest()returns[]immediately unlesspayload.action === 'closed' && payload.pull_request.merged— i.e. it does nothing at all for a PR-opened(orreopened,synchronize, etc.) webhook event.BountiesService.markInReview(id, prUrl, prNumber)exists specifically to transition a bountyCLAIMED -> IN_REVIEWwhen a PR is opened against its issue, but the only place it's ever called is insidehandlePullRequest's merged-PR branch, immediately beforemarkMergedAndRelease— i.e.markInReviewonly ever fires in the same instant as a merge, never in response to the actual "a PR was opened" event that should trigger it.Practical consequence: a contributor who opens a PR that sits open for review (the common case) never sees their bounty move to
IN_REVIEWfrom the webhook's perspective — it staysCLAIMEDin the database (and in any UI readingBounty.status) right up until the PR is merged, at which pointIN_REVIEWandMERGEDboth happen within the same request. This is distinct from the already-filed issue about a PR closed without merging having no handler — this is about PRs that are opened (merged or not) having no handler either. Add a case foraction === 'opened'(and arguably'reopened') that resolves the linked bounty and callsmarkInReviewat the time the PR is actually opened.