Edited comments generate scary error logs instead of being silently ignored

[chmouel]

What's happening

When someone edits an existing comment on a pull request, PAC receives the notification but doesn't know what to do with it (PAC only acts on newly created comments, not edits). Instead of quietly ignoring the event, PAC logs it as an error:

{"level":"error","ts":"2026-04-08T07:15:30.171Z","logger":"pipelinesascode","caller":"adapter/sinker.go:35","msg":"failed to parse event: only newly created comment is supported, received: edited","commit":"d78ef4e","provider":"github","event-id":"b890a710-331a-11f1-9367-6da78867aefc","stacktrace":"github.com/openshift-pipelines/pipelines-as-code/pkg/adapter.(*sinker).processEventPayload\n\tgithub.com/openshift-pipelines/pipelines-as-code/pkg/adapter/sinker.go:35\ngithub.com/openshift-pipelines/pipelines-as-code/pkg/adapter.(*sinker).processEvent\n\tgithub.com/openshift-pipelines/pipelines-as-code/pkg/adapter/sinker.go:76\ngithub.com/openshift-pipelines/pipelines-as-code/pkg/adapter.(*listener).Start.listener.handleEvent.func2.1\n\tgithub.com/openshift-pipelines/pipelines-as-code/pkg/adapter/adapter.go:209"}

Why it's a problem

This is not actually an error — it's a normal, expected situation. Users or bots editing comments is completely routine. The level: error log with a full stacktrace alarms operators and makes them think something is broken, when in reality everything is fine and the event should simply be skipped.

Expected behavior

When PAC receives a webhook for an edited (or deleted) comment, it should silently ignore it — no error, no stacktrace, at most a quiet debug-level log.

Steps to reproduce

1. Have PAC installed and watching a repository
2. Post a comment on a pull request, then edit it
3. Observe the controller logs — the error log with stacktrace appears

[chmouel]

Root cause

When GitHub sends a webhook for an edited comment, PAC correctly recognises it shouldn't act on it — but instead of quietly moving on, it returns an error. That error then gets logged twice at error level, complete with a full stacktrace, making it look like something seriously went wrong.

Other similar "I don't need to do anything here" situations in the codebase are handled by returning a special empty value that tells the system "nothing to see here, skip it". This code path returns an actual error instead.

Fix

Two small changes:

1. pkg/provider/github/parse_payload.go — When the comment action is not "created", log a quiet debug message and return the "skip this" value instead of an error.

2. pkg/provider/github/parse_payload_test.go — Update the corresponding test to expect a silent skip rather than an error.

After the fix, editing a comment will produce no error logs at all — the event is silently dropped, which is the correct behaviour.

[majiayu000]

Hi, I've been looking into this and traced the root cause.

Proposed approach: 1. In pkg/provider/github/parse_payload.go, find the code path handling non-"created" comment actions. Replace the error return with a debug log message and return the special empty/skip value used elsewhere in the codebase for "nothing to do" events. 2. In pkg/provider/github/parse_payload_test.go, update the test for edited comments to expect a skip result instead of an error.

I'll open a draft PR shortly. Happy to adjust based on your preference.