feat(github): say why a webhook delivery changed nothing

[imshashank]

Why

Every GitHub delivery was marked processed, including ones that were signature verified and then dropped on the floor. applyGithubEvent returns early when no github_repository_sync row matches the payload's repository, and the route recorded that identically to a delivery that created git links and moved an issue.

The practical effect: a workspace whose install never bound to a repository looks exactly like one where webhooks never arrive. There was no way to answer "are we receiving webhooks?" from inside the product.

What

applyGithubEvent now returns an ignoredReason, and the route records it on the delivery row using the error column that already existed, with status ignored instead of processed. No migration.

Reason	Meaning
unsupported_event	the parser does not cover that event type
repository_not_connected	no repository sync row matches, the fresh install case
repository_disabled	the repository is connected but switched off
no_issue_identifier	the branch and title mention no issue
no_matching_issue	the identifier names an issue this workspace does not have

A delivery that did the work still lands as processed with error null, and the success response shape is unchanged, so existing callers are unaffected.

Tests

7 new: 4 in packages/services covering each reason and the success case, 3 in the route asserting the row carries status and reason. bun run verify green.

Note

This makes the failure legible, it does not by itself make repositories sync. Merged pull request state is already handled end to end: pullRequestState maps merged and the badge renders "Merged", with a pr_merged notification and the issue advancing to a completed state.

🤖 Generated with Claude Code

Greptile Summary

The PR classifies GitHub webhook deliveries that perform no work as ignored and records a specific reason instead of marking every verified delivery as processed.

• Adds typed ignored outcomes for unsupported events, disconnected or disabled repositories, and unmatched issues.
• Persists ignored status and reason on webhook delivery rows.
• Adds service and route coverage for ignored and processed outcomes.

Confidence Score: 4/5

The PR is not yet safe to merge because ignored deliveries remain eligible for reprocessing and can apply stale webhook events after repository or issue state changes.

The route writes successful no-op deliveries as ignored, but its duplicate gate recognizes only processed as terminal; redelivering the same delivery resets it to received and runs the event application path again.

Files Needing Attention: apps/web/src/app/api/webhooks/github/route.ts

Important Files Changed

Filename	Overview
apps/web/src/app/api/webhooks/github/route.ts	Persists ignored outcomes, but the existing duplicate gate still reprocesses deliveries carrying the new terminal-like ignored status.
packages/services/src/github/apply.ts	Adds explicit ignored reasons to no-op service outcomes while preserving successful processing results.
apps/web/tests/app/api/webhooks/github/route.test.ts	Covers initial ignored and processed persistence but does not alter the outstanding redelivery behavior.
packages/services/tests/github/apply.test.ts	Verifies representative ignored reasons and the successful null-reason result.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Signed GitHub webhook] --> B[Claim delivery row]
  B --> C{Existing status is processed?}
  C -->|Yes| D[Return duplicate]
  C -->|No| E[Reset delivery to received]
  E --> F[Apply GitHub event]
  F --> G{Ignored reason?}
  G -->|No| H[Store processed]
  G -->|Yes| I[Store ignored and reason]
  I -. Redelivery re-enters .-> B

Loading

_{Reviews (2): Last reviewed commit: "feat(github): say why a webhook delivery..." | Re-trigger Greptile}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
orbit	Ready	Preview	Aug 8, 2026 11:40am

[coderabbitai]

Warning

Review limit reached

@imshashank, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 33 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: b73b1d12-8ac4-49bb-819e-ce49cb5f5edf

📥 Commits

Reviewing files that changed from the base of the PR and between 66b8f11 and 48571dc.

📒 Files selected for processing (4)

• apps/web/src/app/api/webhooks/github/route.ts
• apps/web/tests/app/api/webhooks/github/route.test.ts
• packages/services/src/github/apply.ts
• packages/services/tests/github/apply.test.ts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}