Issue Summary

It has been identified a data consistency bug between the Jira Cloud issue changelog and the issue’s current assignee.

For a small subset of issues, the current assignee returned by the canonical issue endpoint:

• GET /rest/api/3/issue/{issueIdOrKey}?fields=assignee

(and also by /issueOwners/{projectId}/issues/{issueId}{})

does not have a corresponding latest “assignee” history event in the issue’s changelog:

• GET /rest/api/3/issue/{issueId}/changelog, or

• GET /rest/api/3/issue/{issueIdOrKey}?expand=changelog

Results:

• Using ?expand=changelog returns the same incomplete set of history entries as the standalone changelog endpoint.

• There is no additional assignee event beyond what they originally saw.

• The changelog is therefore missing the event that would assign the issue to the current assignee.

This breaks the expected invariant that:

Current assignee (from /rest/api/3/issue)
= final state obtained by applying all assignee field events from the changelog to the initial state.

Because of this, it cannot reliably derive the timestamp when the current assignee was set, which is a core requirement for several integrations.

Steps to Reproduce

1. Take an affected issue.

1. Call:
    GET /rest/api/3/issue/{issueIdOrKey}?fields=assignee
   • Observe the current assignee accountId (e.g. currentAssigneeId).

1. Call:
    GET /rest/api/3/issue/{issueIdOrKey}?expand=changelog
   or:
    GET /rest/api/3/issue/{issueId}/changelog
   ensuring you page through all results (startAt / maxResults) if needed.

1. From the returned changelog:

• • Collect all history items where field == "assignee".

• • For each such item, inspect to, toString, tmpToAccountId.

• • Sort by the history group’s created timestamp (ascending).

1. Attempt to find the latest assignee change where:

• • tmpToAccountId == currentAssigneeId (preferred), or

• • to == currentAssigneeId (if tmpToAccountId is missing).

1. Observed behavior:

• • There is no history item that assigns the issue to currentAssigneeId.

• • The last available assignee event in the changelog points to a different accountId, or the changelog stops before the transition to the current assignee.

• • Yet /rest/api/3/issue and /issueOwners/{projectId}/issues/{issueId} both report the current assignee as currentAssigneeId.

1. Adding ?expand=changelog does not add any missing history (i.e., it is not a pagination or expansion mistake).

Expected Results

• The combination of:

• • The issue’s current state from /rest/api/3/issue

• • The full changelog from /rest/api/3/issue/{issueId}/changelog or expand=changelog

should be self‑consistent.

• Specifically, for the assignee field:

• • There should always exist a final history item whose to/tmpToAccountId matches fields.assignee.accountId for the same issue.

• • Consumers should be able to compute “when was the current assignee set?” by taking the created timestamp of that last matching history group.

Actual Results

• For a subset of issues:

• • fields.assignee.accountId (and /issueOwners) report Assignee A as the current assignee.

• • The changelog does not contain any assignee event that sets the assignee to Assignee A.

• • The last assignee event in history points to a different accountId, or history stops earlier.

• This means:

• • The current assignee cannot be computed from history + initial state.

• • The invariant “changelog is a complete event stream for the assignee field” is violated.

• • The assignment timestamp for the current assignee is not derivable from the API.

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available