Add filtering for PRs to match issue filtering behavior

[Bala-Sakabattula]

Summary

This PR adds filtering (and other filter types) to PR handling in upstream_pr.py to ensure consistent filtering behavior between issues and PRs, regardless of which handler path they take.

Problem

Previously, PRs were filtered inconsistently depending on which handler path they used:

• Issue handler path (u_issue.handle_github_message() with is_pr=True): PRs were filtered by labels, milestone, and other configured filters ✅
• PR handler path (u_pr.handle_github_message()): PRs were not filtered at all ❌

This inconsistency meant that PRs coming through the PR handler path would bypass filtering and could create JIRA issues even when they didn't match the configured filter criteria (e.g., missing required labels).

Solution

Added the same filtering logic used in upstream_issue.py to upstream_pr.py's handle_github_message() function. The filtering now supports:

1. Label filtering: PRs must have at least one of the configured labels
2. Milestone filtering: PRs must match the configured milestone number
3. Other field filtering: PRs must match any other configured filter fields (e.g., custom fields)

The same filter configuration (config["sync2jira"]["filters"]["github"][upstream]) is used for both issues and PRs, ensuring consistent behavior.

Changes

• sync2jira/upstream_pr.py: Added filtering logic (lines 52-80) that mirrors the filtering in upstream_issue.py
• tests/test_upstream_pr.py: Added comprehensive test cases to verify all three filtering conditions work correctly

Testing

Added test cases:

• test_handle_github_message_filtering: Tests that PRs are correctly filtered out when they don't match labels, milestone, or other field criteria
• test_handle_github_message_filtering_passes: Tests that PRs pass through when all filters match

[qodo-code-review]

Review Summary by Qodo

Add PR filtering to match issue filtering behavior

✨ Enhancement

Walkthroughs

Description

• Add filtering logic to PR handler matching issue filtering behavior
• Support label, milestone, and custom field filtering for PRs
• Ensure consistent filtering across both issue and PR handler paths
• Add comprehensive test coverage for all filtering conditions

Diagram

flowchart LR
  A["PR Handler"] --> B["Extract Filters Config"]
  B --> C["Check Labels Filter"]
  C --> D["Check Milestone Filter"]
  D --> E["Check Other Fields Filter"]
  E --> F{All Filters Pass?}
  F -->|No| G["Return None"]
  F -->|Yes| H["Process PR"]

Loading

File Changes

1. sync2jira/upstream_pr.py ✨ Enhancement +28/-0

Add filtering logic to PR handler

• Added filter extraction from config for the upstream repository
• Implemented label filtering with set intersection check
• Implemented milestone filtering with number comparison
• Implemented generic field filtering with direct value comparison
• All filters return None if conditions not met, preventing PR processing

sync2jira/upstream_pr.py

---

2. tests/test_upstream_pr.py 🧪 Tests +91/-0

Add comprehensive PR filtering test coverage

• Added test_handle_github_message_filtering to test all three filter types
• Tests label filtering rejection when PR has wrong labels
• Tests milestone filtering rejection when PR has wrong milestone number
• Tests custom field filtering rejection when PR has wrong field value
• Added test_handle_github_message_filtering_passes to verify filters pass correctly
• Verifies PR.from_github is called when all filters match

tests/test_upstream_pr.py

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (2) 📎 Requirement gaps (0)

✅ 1. label["name"] can KeyError 📘 Rule violation ⛯ Reliability

---

Suggestion Impact:

The inline GitHub filter loop (including the vulnerable label["name"] set-comprehension) was removed and replaced with a centralized u_issue._apply_github_filters(...) call, likely to encapsulate safer/validated filter handling instead of direct indexing in this function.

code diff:

-    for key, expected in _filter.items():
-        if key == "labels":
-            # special handling for label: we look for it in the list of PR labels
-            actual = {label["name"] for label in pr.get("labels", [])}
-            if actual.isdisjoint(expected):
-                log.debug("Labels %s not found on PR: %s", expected, upstream)
-                return None
-        elif key == "milestone":
-            # special handling for milestone: use the number
-            milestone = pr.get(key) or {}  # Key might exist with value `None`
-            actual = milestone.get("number")
-            if expected != actual:
-                log.debug("Milestone %s not set on PR: %s", expected, upstream)
-                return None
-        else:
-            # direct comparison
-            actual = pr.get(key)
-            if actual != expected:
-                log.debug(
-                    "Actual %r %r != expected %r on PR %s",
-                    key,
-                    actual,
-                    expected,
-                    upstream,
-                )
-                return None
+    if not u_issue._apply_github_filters(pr, _filter, upstream, item_type="PR"):
+        return None

Description

• The new label-filtering logic assumes every entry in pr.get("labels", []) is a dict containing a
  name key, using label["name"].
• Since the PR payload is an external input, a missing/malformed label element would raise
  KeyError and crash processing instead of failing gracefully (filtering or logging and continuing).
• This is an unhandled edge case and missing input validation at a new failure point introduced by
  the PR.

Code

sync2jira/upstream_pr.py[R55-61]

+    for key, expected in _filter.items():
+        if key == "labels":
+            # special handling for label: we look for it in the list of PR labels
+            actual = {label["name"] for label in pr.get("labels", [])}
+            if actual.isdisjoint(expected):
+                log.debug("Labels %s not found on PR: %s", expected, upstream)
+                return None

Evidence

Compliance requires handling edge cases and validating external inputs. The added set-comprehension
indexes label["name"] directly, which will raise on unexpected/malformed GitHub payloads, and
there is no try/guard around it.

Rule 3: Generic: Robust Error Handling and Edge Case Management
Rule 6: Generic: Security-First Input Validation and Data Handling
sync2jira/upstream_pr.py[55-61]

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 label filtering uses `label["name"]` on external GitHub payload data, which can raise `KeyError` if any label object is missing `name` or is malformed.

## Issue Context
`body`/`pr` come from GitHub webhook/API payloads (external input). The filter path should not crash the handler on unexpected payload shapes.

## Fix Focus Areas
- sync2jira/upstream_pr.py[55-61]

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

---

✅ 2. Logs raw filter mismatch values 📘 Rule violation ⛨ Security

---

Suggestion Impact:

The commit removed the inlined filter-evaluation code that logged raw `actual` and `expected` values (including the highlighted debug log) and replaced it with a call to `_apply_github_filters`, eliminating the sensitive log output from this function.

code diff:

-    for key, expected in _filter.items():
-        if key == "labels":
-            # special handling for label: we look for it in the list of PR labels
-            actual = {label["name"] for label in pr.get("labels", [])}
-            if actual.isdisjoint(expected):
-                log.debug("Labels %s not found on PR: %s", expected, upstream)
-                return None
-        elif key == "milestone":
-            # special handling for milestone: use the number
-            milestone = pr.get(key) or {}  # Key might exist with value `None`
-            actual = milestone.get("number")
-            if expected != actual:
-                log.debug("Milestone %s not set on PR: %s", expected, upstream)
-                return None
-        else:
-            # direct comparison
-            actual = pr.get(key)
-            if actual != expected:
-                log.debug(
-                    "Actual %r %r != expected %r on PR %s",
-                    key,
-                    actual,
-                    expected,
-                    upstream,
-                )
-                return None
+    if not u_issue._apply_github_filters(pr, _filter, upstream, item_type="PR"):
+        return None

Description

• The new debug logging prints actual and expected values for arbitrary filter keys, which may
  include sensitive content from the PR payload depending on configured filters.
• This increases the chance of leaking sensitive data into logs and does not produce structured logs
  as required for secure auditing/monitoring.

Code

sync2jira/upstream_pr.py[R73-79]

+                log.debug(
+                    "Actual %r %r != expected %r on PR %s",
+                    key,
+                    actual,
+                    expected,
+                    upstream,
+                )

Evidence

The secure logging rule requires avoiding sensitive data in logs and favors structured logging. The
new log line emits raw actual values taken from the PR payload and expected values from config,
without redaction/structuring safeguards.

Rule 5: Generic: Secure Logging Practices
sync2jira/upstream_pr.py[73-79]

Agent prompt

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

## Issue description
Debug logs in the new filtering code may leak sensitive PR payload values by logging `actual` and `expected` directly.

## Issue Context
Filter keys are configurable and may reference fields that can contain sensitive content. Logging should be structured and avoid raw payload values unless explicitly redacted.

## Fix Focus Areas
- sync2jira/upstream_pr.py[60-79]

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

---

ⓘ The new review experience is currently in Beta. Learn more

[webbnh]

@Bala-Sakabattula, congratulations the perfect testing coverage for this change! 🏆

However, rather than adding this code here, I think you should refactor the body of upstream_issue.handle_github_message() into a subroutine which we can call from here.

[webbnh]

It looks good, @Bala-Sakabattula. I just have some comments on the tests.

It looks like there are two tests which are now redundant and should probably be dropped. And, it looks like there a few test scenarios that you could add and/or relocate. But, I'll leave that up to you.

There are also a couple of items left over from my earlier review. Let me know if you don't want to proceed with those.

[webbnh]

@Bala-Sakabattula, congratulations the perfect testing coverage for this change! 🏆

I'm afraid I have to take back that trophy -- you missed a branch in passes_github_filters():

if key not in mapped_repos[upstream].get("sync", []):

But, I'm not inclined to block the merge over that. 🙂

IFF you decide to go after that, I have one other nit (which I've "pre-resolved") for your consideration. Otherwise, I think this is good to go as soon as @ralphbean feels up to merging it.