e2e/jira_* teardown deletes nothing and reports success — 255 orphaned issues in the CE sandbox project

[tmatup]

Short version

All four tests/tasks/uipath-maestro-flow/e2e/jira_* tasks ship the same
jira_is.delete_issue(), and it has never deleted an issue. It fails two
independent ways, the helper checks neither, and teardown_jira.py prints
OK: deleted <key> regardless. The sandbox CE project now holds 255 issues,
every one a coder-eval orphan.

Affected: jira_lifecycle, jira_search_triage, jira_create_issue,
jira_get_issue (identical jira_is.py in each).

The two defects, measured (2026-07-30, uip 1.200.0, connection f5273a4d-…)

delete_issue runs uip is resources run delete uipath-atlassian-jira issue --query issueId=<key>.

1. No --yes. The CLI now gates a destructive data operation behind a
confirmation:

{"Result":"Failure",
 "Message":"Confirmation required: this will delete resource 'issue' and cannot be undone.",
 "Instructions":"Re-run with --yes to confirm."}

2. Wrong resource. With --yes added it is still a 404 — DELETE lives on
curated_issue, not issue:

$ … run delete … issue         --query {"issueId":"CE-304"} --yes
{"Result":"Failure","Message":"404 Not Found", …"No API found at that URL for the given token and credentials"}

$ … run delete … curated_issue --query {"issueId":"CE-304"} --yes
{"Result":"Success","Code":"ExecuteOperation","Data":{"Value":""}}
   → and the re-read is a real 404

Why it looks green: jira_is._run() returns the parsed envelope and
delete_issue ignores it, so teardown_jira.py's print(f"OK: deleted {key}")
runs on the failure path too.

The tenant agrees

Census of CE via uip is resources run list uipath-atlassian-jira search_issues_with_fields --query '{"project":"CE","pageSize":100}', 3 pages:

summary prefix	count
coder-eval jira flow e2e …	101
coder-eval jira search-triage …	95
coder-eval jira lifecycle …	59
anything not coder-eval	0
total	255

Spot-checked keys the nightlies' own post_run reported deleting — CE-68,
CE-70 (2026-07-21), CE-108 (07-23), CE-274, CE-276 (07-29): all five
still exist, summaries intact.

Suggested fix

In each jira_is.py:

def delete_issue(conn_id: str, key: str) -> dict:
    return _run(
        "is", "resources", "run", "delete", CONNECTOR, "curated_issue",
        "--connection-id", conn_id, "--query", json.dumps({"issueId": key}),
        "--yes",
    )

and have teardown_jira.py check the envelope (a 404 = already gone, fine;
anything else is a real failure worth printing) and verify by re-reading for a
404. A teardown that cannot fail loudly is a teardown nobody will notice is
broken — which is how this lasted.

A one-off cleanup of the 255 existing issues is also wanted; they are all
identifiable by the coder-eval jira … summary prefix.

Found while porting e2e/jira_lifecycle to the typed-SDK arm
(UiPath/flow-builder-sdk#144 and its PR series). Full evidence, including every
command and response, in that work's probe report.

🤖 Generated with Claude Code