[kayahk]

Why

As suggested in Paca-AI/paca#606 — this belongs here rather than in the core's api_trigger.

createWebhook registered every linked repository for push, pull_request and check_run, but handleWebhookEvent only ever acts on the first two. GitHub sends check_run once per CI job per state, so a repo with ~10 jobs turns one push into dozens of deliveries, and every one of them paid for:

1. a github_repositories lookup, and
2. an HMAC verification,

…before landing in the default: case that logs unhandled event type and returns. That is the same delivery flood that motivated #606 on the core side, and here it is entirely self-inflicted: the plugin asked for an event it does not handle.

It is also not fixable by narrowing the subscription alone — hooks created by earlier versions stay subscribed to check_run until someone deletes and recreates them, so the receiver has to be cheap on its own.

What

• receiveWebhook now checks the event type before the repository lookup and the HMAC work, and answers 204 (unchanged contract, so GitHub never retries) for anything that is not pull_request/push. The check is the same closed set handleWebhookEvent dispatch already had, just moved in front of the expensive part.
• createWebhook no longer subscribes to check_run, so new links stop the traffic at the source.
• README's webhook section updated to match.

No behaviour change for pull_request or push: same signature requirement, same storage, same emitted events.

Tests

• TestHandlesWebhookEvent — the closed set, including check_run, check_suite, workflow_run, empty.
• TestReceiveWebhook_IgnoresUnhandledEventType — a correctly signed check_run delivery against a linked repo answers 204, logs the drop, and never reaches handleWebhookEvent. Fails without the gate (expected the unhandled event to be dropped before dispatch, with the log showing webhook received + unhandled event type).
• Two existing tests (ScopesRepositoryLookupToURLProject, RejectsMissingSecret) used an unhandled event (workflow_run) purely as a vehicle to prove signature verification ran, and used unhandled event type as the positive dispatch signal. They now send pull_request and assert handling pull_request event, which is logged at the same point and stays reachable. Their intent and assertions are otherwise unchanged.
• go test -race ./... green, golangci-lint run → 0 issues.

Not in this PR

Action-level narrowing (e.g. "only opened/synchronize, not labeled") has no home yet: a plugin trigger's config is opaque to the core, which dispatches purely on eventTopic, so per-automation filtering cannot be decided here. Options worth discussing separately: extra topics per action, or a trigger-filter hook in the plugin SDK. Note github.pr_updated is already emitted (with an action field) but not declared as a trigger in plugin.json — declaring it would let automations bind GitHub PR activity without a core api_trigger + public proxy at all.

[pikann]

LGTM! Thank you for the contribution! 🚀