[PeterDaveHello]

Summary

Add regression coverage for signed Gitea pull-request comment webhooks through the real signature-validation, background-task, event-routing, and command-dispatch paths.

This does not change production routing. It documents and protects the webhook contract that the existing routing already implements.

Context

While reviewing Gitea webhook handling, PR timeline comments initially appeared to be missing from the production router: gitea_app.py handles X-Gitea-Event: issue_comment, while Gitea also defines an internal event named pull_request_comment.

Following that mapping through Gitea's webhook implementation shows why the existing routing is correct.

Gitea distinguishes the specific event type from the normalized event sent to webhook consumers:

• HookEventPullRequestComment is delivered as X-Gitea-Event: issue_comment, with X-Gitea-Event-Type: pull_request_comment.
• HookEventPullRequestReviewComment is delivered as X-Gitea-Event: pull_request_comment, with X-Gitea-Event-Type: pull_request_review_comment.

As a result, adding pull_request_comment as an alias for normal PR timeline commands would not fix a missing route. It would instead risk conflating submitted review comments with timeline comments.

The distinction is subtle because the same event names appear at different layers of Gitea's webhook model. These tests make that contract explicit so a future routing change does not accidentally collapse the two event types.

What this covers

• Signed PR timeline comments delivered as issue_comment dispatch /review, /ask, and /improve exactly once with the original command and PR URL.
• Edited or deleted comments do not dispatch commands.
• Missing actions, ordinary comments, empty comment bodies, and missing PR targets are ignored.
• Issue-only comments remain distinct from PR timeline comments.
• Submitted review comments delivered as pull_request_comment are not treated as timeline commands.
• Missing or invalid webhook signatures are rejected before any background task is queued.

The fixtures follow Gitea's native IssueCommentPayload, including issue, pull_request, comment, and is_pull.

Why tests rather than a routing change

The existing production routing already matches Gitea's normalized webhook contract.

The risk is not an uncovered event, but a plausible future change based on the internal event name alone. Exercising the signed HTTP delivery path through background dispatch ensures the behavior is protected at the same boundary where Gitea actually delivers it.

Production code, dependencies, configuration, and workflows are unchanged.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Cover signed Gitea comment webhook dispatch

🧪 Tests 🕐 10-20 Minutes

AI Description

• Covers signed Gitea PR timeline commands through signature validation and background dispatch.
• Protects normalized issue_comment routing from review-comment event conflation.
• Verifies ineligible payloads and rejected signatures never invoke the agent.

Diagram

sequenceDiagram
    actor T as Webhook Tests
    participant E as Gitea Endpoint
    participant V as Signature Check
    participant B as Background Tasks
    participant R as Event Router
    participant A as PR Agent
    T->>E: Signed comment webhook
    E->>V: Verify request body
    alt Valid signature
        V-->>E: Accept
        E->>B: Queue payload
        B->>R: Route normalized event
        opt Created PR command
            R->>A: Dispatch slash command
        end
    else Missing or invalid
        V-->>E: Reject 400 or 401
    end

Loading

High-Level Assessment

The test-only approach is appropriate because production already follows Gitea's normalized webhook contract. Adding pull_request_comment as a timeline-command alias would conflate review comments with PR timeline comments, while narrower router unit tests would miss signature validation and background dispatch behavior.

Files changed (1) +129 / -0

Tests (1) +129 / -0

test_gitea_comment_webhooks.pyAdd signed Gitea comment webhook contract tests +129/-0

Add signed Gitea comment webhook contract tests

• Adds native Gitea webhook fixtures that exercise HMAC validation, task queuing, event routing, and command dispatch. Covers supported timeline commands, ignored payloads, distinct issue and review comments, and missing or invalid signatures.

tests/unittest/test_gitea_comment_webhooks.py

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0) 📜 Skill insights (0)

1. Webhook note uses narrative phrasing 📘 Rule violation ⚙ Maintainability

Description

The comment above test_signed_pr_timeline_comment_dispatches_once describes how Gitea normalizes
the event instead of presenting the guidance as an imperative instruction. When maintainers revisit
this subtle header mapping, the comment does not follow the required instructional convention for
behavioral notes.

Code

tests/unittest/test_gitea_comment_webhooks.py[73]

+    # Gitea normalizes HookEventPullRequestComment to X-Gitea-Event: issue_comment.

Evidence

Compliance rule 2694688 requires newly added behavioral comments to use imperative phrasing. The
added comment at line 73 instead narrates what Gitea does with the event.

Rule 2694688: Docstrings and comments must use imperative phrasing
tests/unittest/test_gitea_comment_webhooks.py[73-73]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The newly added Gitea event-normalization comment uses descriptive phrasing instead of the required imperative phrasing.
## Fix Focus Areas
- tests/unittest/test_gitea_comment_webhooks.py[73-73]
## Recommended Fix
Rewrite the comment as an instruction, such as `# Treat HookEventPullRequestComment as issue_comment after Gitea normalizes it.`

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

• Author self-review: I have reviewed the code review findings, and addressed the relevant ones.

Tip of the day

💡 Did you know, you can turn on the rule miner and Qodo learns your standards from review history

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[IsmaelMartinez]

Thanks for tracing Gitea's event normalisation back to its source and encoding it as a signed end-to-end test rather than a routing change. Approving.

The signature check runs for real: flipping the HMAC comparison turns 13 of 14 cases red, and the missing-header case rightly stays green since it is rejected earlier. None of these entry points had unit coverage before. Qodo's line 73 phrasing note is a platform rule, not this repo's convention, so the comment can stand. CI is green.