[Bug]: jira_update_issue silently drops `parent: null` (clearing epic membership fails but returns success)

[scottirvinsonos]

Summary

jira_update_issue silently drops parent: null (and a null Epic Link customfield). The field is skipped, the parent is left unchanged, but the tool still returns a success response — so callers cannot tell the write failed. Setting a parent works fine; only clearing it is broken. The net effect is that it's impossible to unlink an issue from its epic via jira_update_issue, and the failure is silent.

Environment

• mcp-atlassian 0.21.1
• Jira Cloud, company-managed project
• Transport: stdio; auth: API token (Basic)

Steps to reproduce

1. Link an issue to an epic (works):

   jira_update_issue(issue_key="PROJ-123", fields='{"parent": {"key": "EPIC-1"}}')
   

   → parent and the legacy Epic Link are both set. ✅
2. Try to clear it:

   jira_update_issue(issue_key="PROJ-123", fields='{"parent": null}')
   

   → Tool returns success, but the parent is unchanged. Server log:

   WARNING - mcp-jira - Invalid parent value for issue PROJ-123: None
   

3. Same for clearing the Epic Link customfield directly:

   jira_update_issue(issue_key="PROJ-123", fields='{"customfield_10014": null}')
   

   → Server log: WARNING - mcp-jira - Skipping field 'customfield_10014' due to formatting error or invalid value. Field unchanged; success returned.

Expected behavior

Either actually clear the field when null is passed, or return an explicit error. Silently skipping a requested field while reporting success is data-loss-masking: automation believes the epic was unlinked when it wasn't.

Actual behavior

The field is silently left unchanged and a success response is returned. No error surfaces to the caller.

Impact

Any workflow that needs to remove an issue from an epic (e.g. re-triage / re-parenting automation) silently no-ops. Because there's no error, downstream logic assumes success and the issue lingers in the old epic indefinitely.

Verified workaround (Cloud)

A direct REST call bypasses the tool's field handling and works:

PUT /rest/api/3/issue/{key}
{"fields": {"parent": null}}          # HTTP Basic auth (email:token) → 204

On Cloud company-managed projects this clears the native parent and the synced legacy Epic Link, dropping the issue from "Epic Link" = <epic> membership.

Related

• [Feature]: Support unlinking an issue from an epic (jira_unlink_from_epic or allow null epic_key) #1221 — feature request to support unlinking an issue from an epic. This issue is the underlying silent-failure bug: jira_update_issue already accepts parent/Epic-Link null and returns success, so at minimum it should error instead of silently no-op'ing (and ideally clear the field, which the REST PUT above shows is possible).

[ebarkhordar]

Reproduced the drop on current main (f4f1eb2) in a clean python:3.12-slim container. The field never leaves our code, so it reproduces fully offline (no Jira instance needed) by inspecting what update_issue puts on the wire.

Root cause is the parent branch in IssuesMixin.update_issue (src/mcp_atlassian/jira/issues.py:1223-1231):

elif key == "parent":
    if isinstance(value, dict) and value.get("key"):
        update_fields["parent"] = {"key": str(value["key"])}
    elif isinstance(value, str) and value:
        update_fields["parent"] = {"key": value}
    else:
        logger.warning(f"Invalid parent value for issue {issue_key}: {value}")

A None (from fields='{"parent": null}', which the tool spreads into parent=None) matches neither the dict-with-key nor the non-empty-str case, so it lands in the else: a warning is logged and nothing is added to update_fields. With no other fields in the request, the if update_fields: block is skipped entirely, so no PUT is sent. The method then falls through to the get_issue re-fetch and returns the unchanged issue, so the caller sees success.

What I observed in the container, driving the real method with the outbound API call captured:

SET   parent={"key":"EPIC-1"}  -> outbound fields: {'parent': {'key': 'EPIC-1'}}
CLEAR parent=None              -> WARNING Invalid parent value for issue PROJ-123: None
                                  outbound fields: None   (no write sent)
                                  returned key: PROJ-123  (success)

So this is verified at the request boundary: setting a parent is sent, clearing it is silently swallowed and reported as success. I did not exercise a live Jira, so I am only claiming what our code emits, not Jira's acceptance of any particular clear payload.

The assignee branch a few lines up (issues.py:1197-1200) already handles exactly this shape, treating None/"" as an explicit unassign, and its comment notes that swallowing an explicit update while still reporting the issue as updated is the failure mode to avoid. The parent branch just never got the same treatment. Mirroring it (route an explicit None/"" to a clear rather than the warn-and-drop else) would fix the silent part; the exact payload Jira wants for a parent clear versus the legacy Epic Link customfield is your call.

[amitvijapur]

Confirmed — in IssuesMixin.update_issue, parent: null falls into the branch's else case (it only recognizes a dict-with-key or non-empty string), logs a warning, and never reaches the API, so the call reports success without clearing the parent. Fix mirrors the existing assignee None-handling a few lines above. Opening a PR now.