INTEROP-9373: fix(jira): handle epic lookup failure gracefully in create_issue

[amp-rh]

TL;DR

Epic lookup failure in create_issue() no longer crashes the report run. The issue is filed successfully; only the epic link is skipped.

Problem

When the Firewatch SA cannot access the configured epic (HTTP 404/403, e.g. project permissions or a stale epic key), search_issues() raises a JIRAError that propagates up unhandled. This has two consequences:

1. Crash stops processing: remaining tickets in the batch are never filed
2. Duplicate tickets: the @ignore_exceptions(retry=3, raise_final_exception=True) decorator retries the entire create_issue() method, re-creating the issue that was already filed before the epic lookup failed

Fix

One file changed: src/objects/jira_base.py

The epic link is a nice-to-have for ticket organization; the critical function is filing the ticket itself. This change:

• Wraps the epic search + add_issues_to_epic block in try/except JIRAError
• Downgrades LOGGER.error to LOGGER.warning (non-fatal)
• Adds exc_info=True to preserve chained transport exception tracebacks for debugging
• Returns the issue successfully with all other fields (labels, assignee, attachments) intact

The happy path (epic accessible) is unchanged.

Test plan

One file changed: tests/unittests/objects/jira/test_jira.py

Test	Scenario	Assertion
test_epic_lookup_jira_error_does_not_crash	search_issues raises JIRAError(404)	Issue returned, no exception, warning logged
test_epic_lookup_empty_results_warns_without_error	search_issues returns []	Issue returned, warning (not error) logged
test_add_issues_to_epic_jira_error_does_not_crash	Search succeeds but add_issues_to_epic raises JIRAError(403)	Issue returned, no exception, warning logged
test_epic_lookup_uses_unquoted_issue_key_for_cloud_compatibility	Happy path (existing test)	Unchanged, still passes

Full Jira test suite: 52/52 passing.

[redhat-chai-bot]

Review: Changes look great 👍

I've reviewed both commits and the changes fully address the prior feedback. Here's my assessment:

Production code (jira_base.py) ✅

• try/except scope is correct — wraps both search_issues and add_issues_to_epic, so either failure is handled gracefully without crashing create_issue.
• Severity downgrade from error → warning — appropriate. The issue was created successfully; the epic link is a best-effort enhancement, not a hard requirement.
• exc_info=True — included on the except JIRAError path as requested, so the full traceback will appear in debug-level logs without cluttering normal output. Correctly omitted from the empty-results warning path (no exception in context there).
• Log messages are informative — include the epic key, the issue key, the HTTP status code, and the error text. Good for troubleshooting.

Tests (test_jira.py) ✅

All three failure branches are covered:

Test	Scenario	Key assertions
test_epic_lookup_jira_error_does_not_crash	search_issues raises JIRAError(404)	Issue created, add_issues_to_epic never called, warning logged
test_epic_lookup_empty_results_warns_without_error	search_issues returns []	Issue created, no epic link, warning logged
test_add_issues_to_epic_jira_error_does_not_crash	add_issues_to_epic raises JIRAError(403)	Issue created, add_issues_to_epic was called (and failed), warning logged

The third test is exactly the scenario from the prior review — a permission failure during the epic link step, not during the search step. Nice.

One optional suggestion (non-blocking)

The test_add_issues_to_epic_jira_error_does_not_crash test could additionally verify that exc_info=True was passed to the logger:

assert mock_logger.warning.call_args[1].get("exc_info") is True

This would confirm the traceback inclusion is tested, not just present in the source. But this is minor — the current assertions on the message content are the more important checks.

Verdict

No remaining concerns. LGTM — ready to merge once CI is green. 🚀

---

AI-generated. Review for accuracy.