Add consolidation label processing to TODO fetcher

[majamassarini]

Summary

Add ymir_consolidate_base and ymir_consolidate_next labels to the TODO fetcher query for faster consolidation job submission (5 minutes instead of up to 24 hours).

Change

Updated TODO fetcher JQL query to include consolidation labels:

project = RHEL AND (labels = "ymir_todo" OR labels IN ("ymir_consolidate_base", "ymir_consolidate_next")) AND labels != "sustaining"

Impact

• Responsiveness: Max delay drops from 24h (daily fetcher) to 5min (TODO fetcher)
• Redundancy: Both fetchers process consolidation labels, but submit_merge_job() deduplication prevents duplicate submissions
• Overhead: Negligible - just label scanning on already-fetched issues
• Code changes: None - _process_consolidation_labels() already called by both fetchers

Background

Consolidation is a manual operation where users add labels to two issues to trigger MR consolidation. The daily fetcher (8am UTC) already processes these labels, but this adds a faster path through the TODO fetcher which runs every 5 minutes.

[qodo-for-packit]

PR Summary by Qodo

Include consolidation labels in TODO fetcher JQL for faster job submission

✨ Enhancement ⚙️ Configuration changes 🕐 Less than 5 minutes

AI Description

• Expand TODO fetcher JQL to include consolidation trigger labels.
• Reduce consolidation submission latency from daily to ~5-minute polling.
• Preserve deduplication behavior by relying on existing job submission safeguards.

Diagram

graph TD
  A["OpenShift ConfigMap"] --> B["TODO fetcher"] --> C[("Jira") ] --> D["submit_merge_job()"] --> E[("Job queue")]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Dedicated consolidation-only poller (5 min)

• ➕ Avoids redundant scanning/processing in the TODO fetcher
• ➕ Keeps TODO semantics strictly limited to ymir_todo tickets
• ➖ Adds another deployment/schedule to operate and monitor
• ➖ More moving parts than a simple query expansion

2. Event-driven trigger (Jira webhook/automation)

• ➕ Near-instant reaction to label changes without polling
• ➕ Reduces load from periodic Jira queries
• ➖ Requires Jira-side configuration and reliable delivery/verification
• ➖ More complex failure modes (missed events, retries, auth rotation)

3. Move consolidation labels entirely to TODO fetcher; retire daily path

• ➕ Single source of truth for consolidation trigger processing
• ➕ Less duplication across fetchers
• ➖ Behavior change may impact expectations around the daily fetcher
• ➖ Requires confidence that TODO fetcher coverage is complete and reliable

Recommendation: The PR’s approach (expanding the TODO fetcher JQL) is the best low-risk change for improving responsiveness: it requires no code changes, leverages existing consolidation-label processing already invoked by the fetcher run, and relies on existing submission deduplication to prevent duplicates. The alternatives add operational complexity (new poller) or require upstream infrastructure/process changes (webhooks).

Files changed (1) +1 / -1

Other (1) +1 / -1

configmap-jira-issue-fetcher-todo-env.ymlExpand TODO fetcher JQL to include consolidation labels +1/-1

Expand TODO fetcher JQL to include consolidation labels

• Updates the QUERY JQL to match issues labeled with ymir_todo as well as ymir_consolidate_base/ymir_consolidate_next, while still excluding sustaining. This enables consolidation-labeled issues to be picked up by the 5-minute TODO fetcher schedule instead of waiting for the daily fetcher.

openshift/configmap-jira-issue-fetcher-todo-env.yml

[qodo-for-packit]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

1. Auth failure deletes labels ✓ Resolved 🐞 Bug ☼ Reliability

Description

_label_added_by_rh_employee() returns False on Jira 401/403, and
_process_consolidation_labels() treats False as “not RH employee” and removes
ymir_consolidate_* labels. This can silently delete valid consolidation requests during temporary
auth/permission issues, preventing job submission until humans re-add labels.

Code

ymir/jira_issue_fetcher/jira_issue_fetcher.py[R851-856]

+                if not is_rh_employee:
+                    logger.warning(
+                        f"Issue {issue_key} has {JiraLabels.CONSOLIDATE_BASE.value} but the label "
+                        f"was not added by a Red Hat Employee - skipping and removing the label"
+                    )
+                    labels_to_remove.append(JiraLabels.CONSOLIDATE_BASE.value)

Relevance

●●● Strong

PR #540 accepted this exact Jira auth-verification failure pattern and required skipping rather than
deleting labels.

PR-#540

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The consolidation flow removes labels whenever _label_added_by_rh_employee() returns False, but
the helper explicitly returns False for HTTP 401/403, so auth/permission problems are treated the
same as an untrusted label add and lead to destructive label removal.

ymir/jira_issue_fetcher/jira_issue_fetcher.py[302-309]
ymir/jira_issue_fetcher/jira_issue_fetcher.py[851-888]
PR-#540

Agent prompt

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

### Issue description
Consolidation-label verification currently removes `ymir_consolidate_base` / `ymir_consolidate_next` when `_label_added_by_rh_employee()` returns `False`. Because `_label_added_by_rh_employee()` maps HTTP 401/403 to `False`, a Jira auth/permission outage can cause the fetcher to *delete valid user trigger labels*, losing consolidation requests.

### Issue Context
Callers already treat raised `requests.RequestException` as transient (skip for this sweep). The problem is that 401/403 are suppressed inside `_label_added_by_rh_employee()` and converted into `False`, which the consolidation flow interprets as a verified “not RH employee” result.

### Fix Focus Areas
- ymir/jira_issue_fetcher/jira_issue_fetcher.py[302-309]
- ymir/jira_issue_fetcher/jira_issue_fetcher.py[836-889]

### Suggested fix
- Change `_label_added_by_rh_employee()` so 401/403 **do not** return `False`.
 - Option A (simplest): re-raise for 401/403 (treat as transient/fatal), letting callers skip without label removal.
 - Option B: return a tri-state (e.g., `True`/`False`/`None`) where `None` means “unable to verify,” and have `_process_consolidation_labels()` skip without removing on `None`.
- Ensure `_process_consolidation_labels()` only removes consolidation labels when verification *positively* determines the label was added by a non-RH user (not when verification failed due to auth/permission).

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

---

2. Unverified consolidation trigger ✓ Resolved 🐞 Bug ⛨ Security

Description

By adding consolidation labels to the TODO fetcher QUERY, issues with
ymir_consolidate_base/ymir_consolidate_next will now trigger consolidation job submission every 5
minutes, but consolidation processing does not verify the label was added by a Red Hat Employee. The
code explicitly treats label triggers as potentially coming from “external collaborators” for
ymir_todo, so this expands an unverified trigger path for consolidation labels.

Code

openshift/configmap-jira-issue-fetcher-todo-env.yml[3]

+  QUERY: 'project = RHEL AND (labels = "ymir_todo" OR labels IN ("ymir_consolidate_base", "ymir_consolidate_next")) AND labels != "sustaining"'

Relevance

●●● Strong

Accepted history supports security fixes for untrusted label triggers and unsafe automation paths.

PR-#540
PR-#657

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The ConfigMap change makes the 5-minute TODO cron fetch consolidation-labeled issues. The codebase
already treats label triggers as potentially untrusted (external collaborators) and adds an
RH-employee verification specifically for ymir_todo, but the consolidation-label path submits jobs
without any equivalent verification, so this PR expands an unverified trigger path to run every 5
minutes.

openshift/configmap-jira-issue-fetcher-todo-env.yml[1-4]
openshift/cronjob-jira-issue-fetcher-todo.yml[8-13]
ymir/jira_issue_fetcher/jira_issue_fetcher.py[226-241]
ymir/jira_issue_fetcher/jira_issue_fetcher.py[575-623]
ymir/jira_issue_fetcher/jira_issue_fetcher.py[807-883]
PR-#540

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 TODO fetcher now fetches issues with consolidation labels and the fetcher submits consolidation jobs for them, but `_process_consolidation_labels()` lacks the Red Hat employee author verification that exists for `ymir_todo`. This can allow untrusted label additions (the code explicitly mentions “external collaborator” risk for label triggers) to submit consolidation jobs.

## Issue Context
- TODO fetcher cron runs every 5 minutes and now includes consolidation labels in JQL.
- `ymir_todo` is guarded by `_label_added_by_rh_employee(...)`, but consolidation labels are not.

## Fix Focus Areas
- ymir/jira_issue_fetcher/jira_issue_fetcher.py[226-310]
- ymir/jira_issue_fetcher/jira_issue_fetcher.py[550-623]
- ymir/jira_issue_fetcher/jira_issue_fetcher.py[807-943]

## Suggested fix approach
- Extend `_label_added_by_rh_employee` (or add a new helper) to verify the author of the most-recent add event for `ymir_consolidate_base` and `ymir_consolidate_next`.
- In `_process_consolidation_labels`, before calling `submit_merge_job`, require both labels’ add authors to be RH employees (or otherwise explicitly trusted) and skip/clean up labels if verification fails (similar to the `ymir_todo` flow).

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

---

3. Misleading dedup comments ✓ Resolved 🐞 Bug ≡ Correctness

Description

With consolidation labels now processed by the TODO fetcher as well as the daily fetcher, a timing
overlap can cause submit_merge_job() to return False (pending job already exists) for the second
run. _process_consolidation_labels() still posts a comment stating “MR consolidation job
submitted…”, which can create misleading and duplicate Jira comments.

Code

openshift/configmap-jira-issue-fetcher-todo-env.yml[3]

+  QUERY: 'project = RHEL AND (labels = "ymir_todo" OR labels IN ("ymir_consolidate_base", "ymir_consolidate_next")) AND labels != "sustaining"'

Relevance

●●● Strong

Duplicate Jira comments are accepted when repeated processing can create redundant notifications or
misleading status.

PR-#611
PR-#540

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The repo defines two cronjobs running the same fetcher image (daily and every 5 minutes).
submit_merge_job returns False when a pending job already exists, and
_process_consolidation_labels currently posts the same “job submitted” comment regardless of that
return value, so an overlap can generate misleading/duplicate comments once the TODO fetcher starts
fetching consolidation labels.

openshift/cronjob-jira-issue-fetcher.yml[8-44]
openshift/cronjob-jira-issue-fetcher-todo.yml[8-44]
ymir/jira_issue_fetcher/jira_issue_fetcher.py[945-961]
ymir/common/merge_queue.py[20-55]
ymir/jira_issue_fetcher/jira_issue_fetcher.py[893-923]

Agent prompt

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

## Issue description
When `submit_merge_job(...)` returns `False` (pending job already exists), `_process_consolidation_labels()` still posts the same “MR consolidation job submitted…” comment. After this PR, two cronjobs (daily + every-5-min TODO) can process the same consolidation labels, making this misleading-comment path more likely.

## Issue Context
- `submit_merge_job` returns `False` if a pending job exists.
- `_process_consolidation_labels` logs this case but still posts the “job submitted” comment unconditionally.

## Fix Focus Areas
- ymir/jira_issue_fetcher/jira_issue_fetcher.py[875-924]
- ymir/common/merge_queue.py[20-55]

## Suggested fix approach
- If `submit_merge_job(...)` returns `True`, post the “submitted” comment.
- If it returns `False`, either (a) skip commenting entirely, or (b) post a distinct message like “Consolidation job already queued for package/branch; labels cleared.” (and avoid posting it twice if both issues are processed).

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

---

4. Duplicate auth error logging ✗ Dismissed 🐞 Bug ◔ Observability ⭐ New

Description

On 401/403, _label_added_by_rh_employee() logs a warning and re-raises, and its callers also log
the caught RequestException, producing two warnings per issue. During auth/permission outages this
can create significant log noise in the 5-minute fetcher.

Code

ymir/jira_issue_fetcher/jira_issue_fetcher.py[R308-311]

+                        f"Auth/permission error verifying {label} author on {issue_key}: {e}; "
+                        f"will retry next sweep (not removing label)"
+                    )
+                    raise

Relevance

●●● Strong

Accepted precedent supports propagating auth failures to callers; removing duplicate helper logging
is a localized observability fix.

PR-#540

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The helper logs a warning and re-raises on 401/403, while both call sites that handle the exception
also emit warnings, resulting in duplicated log entries for the same failure.

ymir/jira_issue_fetcher/jira_issue_fetcher.py[302-312]
ymir/jira_issue_fetcher/jira_issue_fetcher.py[595-608]
ymir/jira_issue_fetcher/jira_issue_fetcher.py[849-859]

Agent prompt

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

### Issue description
`_label_added_by_rh_employee()` logs a warning for 401/403 and then re-raises the exception; callers (`push_issues_to_queue()` and `_process_consolidation_labels()`) also log when catching `requests.RequestException`, causing duplicate warning lines per failed verification.

### Issue Context
This is most visible during Jira auth/permission outages (401/403), where the TODO fetcher runs every 5 minutes and may process many issues.

### Fix Focus Areas
- ymir/jira_issue_fetcher/jira_issue_fetcher.py[302-312]

### Suggested fix
Choose a single layer to log the auth/permission failure:
- Option A (simplest): remove/downgrade the `logger.warning(...)` inside the 401/403 branch in `_label_added_by_rh_employee()` and just `raise`, relying on the caller’s warning.
- Option B: keep the helper warning but adjust callers to avoid logging again when the exception is an HTTPError with status 401/403.

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

---

5. Outdated TODO fetcher docs ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

openshift/README.md still documents the TODO fetcher QUERY as only labels = "ymir_todo", but the
TODO ConfigMap now includes consolidation labels as well. This discrepancy can mislead operators
during troubleshooting and future config changes.

Code

openshift/configmap-jira-issue-fetcher-todo-env.yml[3]

+  QUERY: 'project = RHEL AND (labels = "ymir_todo" OR labels IN ("ymir_consolidate_base", "ymir_consolidate_next")) AND labels != "sustaining"'

Relevance

●●● Strong

Documentation updates reflecting deployment configuration are accepted, including OpenShift README
corrections.

PR-#703
PR-#651

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The README explicitly lists the TODO fetcher query as ymir_todo-only, while the ConfigMap in this PR
changes the actual deployed QUERY to include consolidation labels.

openshift/README.md[122-130]
openshift/configmap-jira-issue-fetcher-todo-env.yml[1-4]

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 OpenShift README documents the TODO fetcher JQL as `labels = "ymir_todo"`, but the deployed ConfigMap now uses a broader query including consolidation labels.

## Issue Context
This PR changes the ConfigMap but does not update the corresponding docs.

## Fix Focus Areas
- openshift/README.md[122-130]
- openshift/configmap-jira-issue-fetcher-todo-env.yml[1-4]

## Suggested fix approach
Update the README table row and explanatory text to reflect the new query (or reference the configmap file as the source of truth).

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

---

Context sources

✅ Compliance rules (platform): 7 rules

Tip of the day

💡 Did you know, you can copy the agent prompt from any finding and feed it to your IDE agent

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous reviews

Review updated until commit 61d44f7

Results up to commit 9b3d122 ⚖️ Balanced

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Unverified consolidation trigger ✓ Resolved 🐞 Bug ⛨ Security

Description

By adding consolidation labels to the TODO fetcher QUERY, issues with
ymir_consolidate_base/ymir_consolidate_next will now trigger consolidation job submission every 5
minutes, but consolidation processing does not verify the label was added by a Red Hat Employee. The
code explicitly treats label triggers as potentially coming from “external collaborators” for
ymir_todo, so this expands an unverified trigger path for consolidation labels.

Code

openshift/configmap-jira-issue-fetcher-todo-env.yml[3]

+  QUERY: 'project = RHEL AND (labels = "ymir_todo" OR labels IN ("ymir_consolidate_base", "ymir_consolidate_next")) AND labels != "sustaining"'

Relevance

●●● Strong

Accepted history supports security fixes for untrusted label triggers and unsafe automation paths.

PR-#540
PR-#657

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The ConfigMap change makes the 5-minute TODO cron fetch consolidation-labeled issues. The codebase
already treats label triggers as potentially untrusted (external collaborators) and adds an
RH-employee verification specifically for ymir_todo, but the consolidation-label path submits jobs
without any equivalent verification, so this PR expands an unverified trigger path to run every 5
minutes.

openshift/configmap-jira-issue-fetcher-todo-env.yml[1-4]
openshift/cronjob-jira-issue-fetcher-todo.yml[8-13]
ymir/jira_issue_fetcher/jira_issue_fetcher.py[226-241]
ymir/jira_issue_fetcher/jira_issue_fetcher.py[575-623]
ymir/jira_issue_fetcher/jira_issue_fetcher.py[807-883]
PR-#540

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 TODO fetcher now fetches issues with consolidation labels and the fetcher submits consolidation jobs for them, but `_process_consolidation_labels()` lacks the Red Hat employee author verification that exists for `ymir_todo`. This can allow untrusted label additions (the code explicitly mentions “external collaborator” risk for label triggers) to submit consolidation jobs.

## Issue Context
- TODO fetcher cron runs every 5 minutes and now includes consolidation labels in JQL.
- `ymir_todo` is guarded by `_label_added_by_rh_employee(...)`, but consolidation labels are not.

## Fix Focus Areas
- ymir/jira_issue_fetcher/jira_issue_fetcher.py[226-310]
- ymir/jira_issue_fetcher/jira_issue_fetcher.py[550-623]
- ymir/jira_issue_fetcher/jira_issue_fetcher.py[807-943]

## Suggested fix approach
- Extend `_label_added_by_rh_employee` (or add a new helper) to verify the author of the most-recent add event for `ymir_consolidate_base` and `ymir_consolidate_next`.
- In `_process_consolidation_labels`, before calling `submit_merge_job`, require both labels’ add authors to be RH employees (or otherwise explicitly trusted) and skip/clean up labels if verification fails (similar to the `ymir_todo` flow).

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

---

2. Misleading dedup comments ✓ Resolved 🐞 Bug ≡ Correctness

Description

With consolidation labels now processed by the TODO fetcher as well as the daily fetcher, a timing
overlap can cause submit_merge_job() to return False (pending job already exists) for the second
run. _process_consolidation_labels() still posts a comment stating “MR consolidation job
submitted…”, which can create misleading and duplicate Jira comments.

Code

openshift/configmap-jira-issue-fetcher-todo-env.yml[3]

+  QUERY: 'project = RHEL AND (labels = "ymir_todo" OR labels IN ("ymir_consolidate_base", "ymir_consolidate_next")) AND labels != "sustaining"'

Relevance

●●● Strong

Duplicate Jira comments are accepted when repeated processing can create redundant notifications or
misleading status.

PR-#611
PR-#540

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The repo defines two cronjobs running the same fetcher image (daily and every 5 minutes).
submit_merge_job returns False when a pending job already exists, and
_process_consolidation_labels currently posts the same “job submitted” comment regardless of that
return value, so an overlap can generate misleading/duplicate comments once the TODO fetcher starts
fetching consolidation labels.

openshift/cronjob-jira-issue-fetcher.yml[8-44]
openshift/cronjob-jira-issue-fetcher-todo.yml[8-44]
ymir/jira_issue_fetcher/jira_issue_fetcher.py[945-961]
ymir/common/merge_queue.py[20-55]
ymir/jira_issue_fetcher/jira_issue_fetcher.py[893-923]

Agent prompt

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

## Issue description
When `submit_merge_job(...)` returns `False` (pending job already exists), `_process_consolidation_labels()` still posts the same “MR consolidation job submitted…” comment. After this PR, two cronjobs (daily + every-5-min TODO) can process the same consolidation labels, making this misleading-comment path more likely.

## Issue Context
- `submit_merge_job` returns `False` if a pending job exists.
- `_process_consolidation_labels` logs this case but still posts the “job submitted” comment unconditionally.

## Fix Focus Areas
- ymir/jira_issue_fetcher/jira_issue_fetcher.py[875-924]
- ymir/common/merge_queue.py[20-55]

## Suggested fix approach
- If `submit_merge_job(...)` returns `True`, post the “submitted” comment.
- If it returns `False`, either (a) skip commenting entirely, or (b) post a distinct message like “Consolidation job already queued for package/branch; labels cleared.” (and avoid posting it twice if both issues are processed).

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

---

3. Outdated TODO fetcher docs ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

openshift/README.md still documents the TODO fetcher QUERY as only labels = "ymir_todo", but the
TODO ConfigMap now includes consolidation labels as well. This discrepancy can mislead operators
during troubleshooting and future config changes.

Code

openshift/configmap-jira-issue-fetcher-todo-env.yml[3]

+  QUERY: 'project = RHEL AND (labels = "ymir_todo" OR labels IN ("ymir_consolidate_base", "ymir_consolidate_next")) AND labels != "sustaining"'

Relevance

●●● Strong

Documentation updates reflecting deployment configuration are accepted, including OpenShift README
corrections.

PR-#703
PR-#651

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The README explicitly lists the TODO fetcher query as ymir_todo-only, while the ConfigMap in this PR
changes the actual deployed QUERY to include consolidation labels.

openshift/README.md[122-130]
openshift/configmap-jira-issue-fetcher-todo-env.yml[1-4]

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 OpenShift README documents the TODO fetcher JQL as `labels = "ymir_todo"`, but the deployed ConfigMap now uses a broader query including consolidation labels.

## Issue Context
This PR changes the ConfigMap but does not update the corresponding docs.

## Fix Focus Areas
- openshift/README.md[122-130]
- openshift/configmap-jira-issue-fetcher-todo-env.yml[1-4]

## Suggested fix approach
Update the README table row and explanatory text to reflect the new query (or reference the configmap file as the source of truth).

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

---

Results up to commit 861fd71 ⚖️ Balanced

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Auth failure deletes labels ✓ Resolved 🐞 Bug ☼ Reliability

Description

_label_added_by_rh_employee() returns False on Jira 401/403, and
_process_consolidation_labels() treats False as “not RH employee” and removes
ymir_consolidate_* labels. This can silently delete valid consolidation requests during temporary
auth/permission issues, preventing job submission until humans re-add labels.

Code

ymir/jira_issue_fetcher/jira_issue_fetcher.py[R851-856]

+                if not is_rh_employee:
+                    logger.warning(
+                        f"Issue {issue_key} has {JiraLabels.CONSOLIDATE_BASE.value} but the label "
+                        f"was not added by a Red Hat Employee - skipping and removing the label"
+                    )
+                    labels_to_remove.append(JiraLabels.CONSOLIDATE_BASE.value)

Relevance

●●● Strong

PR #540 accepted this exact Jira auth-verification failure pattern and required skipping rather than
deleting labels.

PR-#540

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The consolidation flow removes labels whenever _label_added_by_rh_employee() returns False, but
the helper explicitly returns False for HTTP 401/403, so auth/permission problems are treated the
same as an untrusted label add and lead to destructive label removal.

ymir/jira_issue_fetcher/jira_issue_fetcher.py[302-309]
ymir/jira_issue_fetcher/jira_issue_fetcher.py[851-888]
PR-#540

Agent prompt

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

### Issue description
Consolidation-label verification currently removes `ymir_consolidate_base` / `ymir_consolidate_next` when `_label_added_by_rh_employee()` returns `False`. Because `_label_added_by_rh_employee()` maps HTTP 401/403 to `False`, a Jira auth/permission outage can cause the fetcher to *delete valid user trigger labels*, losing consolidation requests.

### Issue Context
Callers already treat raised `requests.RequestException` as transient (skip for this sweep). The problem is that 401/403 are suppressed inside `_label_added_by_rh_employee()` and converted into `False`, which the consolidation flow interprets as a verified “not RH employee” result.

### Fix Focus Areas
- ymir/jira_issue_fetcher/jira_issue_fetcher.py[302-309]
- ymir/jira_issue_fetcher/jira_issue_fetcher.py[836-889]

### Suggested fix
- Change `_label_added_by_rh_employee()` so 401/403 **do not** return `False`.
 - Option A (simplest): re-raise for 401/403 (treat as transient/fatal), letting callers skip without label removal.
 - Option B: return a tri-state (e.g., `True`/`False`/`None`) where `None` means “unable to verify,” and have `_process_consolidation_labels()` skip without removing on `None`.
- Ensure `_process_consolidation_labels()` only removes consolidation labels when verification *positively* determines the label was added by a non-RH user (not when verification failed due to auth/permission).

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

---

[majamassarini]

/agentic_review

[qodo-for-packit]

Code review by qodo was updated up to the latest commit 861fd71

[majamassarini]

/agentic_review

[qodo-for-packit]

Code review by qodo was updated up to the latest commit 03c7c49

[TomasTomecek]

amazing! thank you

[TomasTomecek]

nice! we can mark this as mitigated in the threat model

[majamassarini]

Oh I thought this was already mentioned in the threat model document. I remember a comment about it. But I would double check.

[lbarcziova]

thanks!