[MM-69266] Fix false "No webhook was found" warning when only an org-…#1027
[MM-69266] Fix false "No webhook was found" warning when only an org-…#1027nang2049 wants to merge 2 commits into
Conversation
…level webhook exists
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthrough
ChangesWebhook Existence Check Refactor
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@server/plugin/command.go`:
- Around line 455-458: The error handling block checks for cErr but then uses
listErr in both the log message and return statement, which could be nil and
cause a panic. In the condition where cErr is non-nil, replace all references to
listErr with cErr in the processLogger.Warn call and the return statement to log
and return the actual error from the useGitHubClient operation.
- Around line 466-468: The pagination logic at line 466-468 checks resp.NextPage
without first verifying that resp itself is not nil, which can cause a nil
pointer dereference when the GitHub API returns a nil response in edge cases.
Update the condition to include a nil check for resp before accessing its
NextPage property, following the pattern already established in sla_digest.go
where both conditions are checked together: first verify resp is not nil, then
check if resp.NextPage equals zero.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 8c7c4ebc-4d4e-4db0-9a05-566a3b613784
📒 Files selected for processing (1)
server/plugin/command.go
Summary
When a channel is subscribed to a specific repository via
/github subscribe owner/repoand webhook delivery is handled by an org level webhook the plugin incorrectly posts:Ticket Link
https://mattermost.atlassian.net/browse/MM-69266
QA
<org>- Settings - Webhooks add a webhook with Payload URLhttps://<mattermost>/plugins/github/webhook./github subscribe <org>/<repo>.Change Impact: 🟡 Medium
Reasoning: This PR modifies webhook verification logic in a critical user-facing flow (subscription creation), changing the behavior for organization-level webhook detection and error handling. While the changes are isolated to the
command.gofile and fix a legitimate false-negative issue, the lack of dedicated test coverage for the modified functions and the introduction of special error handling logic (treating 403/404 API errors as success) creates moderate regression risk.Regression Risk: The changes affect
checkIfConfiguredWebhookExists, which is called during repository subscriptions inhandleSubscribesAddand repository unsubscriptions. The refactored logic introduces a fallback pattern where if repository-level webhook listing fails with 403/404 errors, the function returns success rather than failure, and then attempts organization-level webhook checking. This behavioral change could mask genuine permission issues and result in users seeing subscription success messages when they should be warned about missing webhooks. The addition ofisWebhookListAccessErrorcentralizes error detection, but the interpretation of these errors as a sign that webhooks "effectively exist" may not account for all failure scenarios. No specific test cases for these functions were found incommand_test.godespite 24 existing test functions in that file.QA Recommendation: Comprehensive manual QA is recommended before production release. Test scenarios should include: (1) repositories with both repository-level and organization-level webhooks configured; (2) repositories with only organization-level webhooks; (3) users with insufficient permissions to list repository webhooks (403 errors); (4) repositories where webhook access is completely denied (404 errors); (5) edge cases where organization webhook listing fails after successful repository webhook check. At minimum, verify that the warning message appears/disappears correctly in all webhook configuration scenarios described in the QA steps. Automated test coverage should be added for
checkIfConfiguredWebhookExistsandanyHookMatchesSiteURLfunctions before merging, particularly for the new fallback and error handling logic.