Internal Server Error (NullPointerException) when clicking on JIRA issue keys in Fisheye
Symptoms
Clicking on a JIRA issue key in Fisheye 3.1 or newer (which will open up a window showing the issue information in Fisheye) throws an Internal Server error.
The following appears in the atlassian-jira.log
:
2014-02-27 10:56:54,465 http-bio-8081-exec-4 ERROR xxxx 656x1087x1 11pfuij xx.xx.xx.xx,127.0.0.1 /rest/api/2/search [jira.rest.exception.ExceptionInterceptor] Returning internal server error in response
java.lang.reflect.InvocationTargetException
[...]
Caused by: java.lang.NullPointerException
at com.atlassian.jira.rest.v2.issue.TransitionMetaBeanBuilder.getStatusFromStep(TransitionMetaBeanBuilder.java:83)
at com.atlassian.jira.rest.v2.issue.TransitionMetaBeanBuilder.build(TransitionMetaBeanBuilder.java:69)
at com.atlassian.jira.rest.v2.issue.IssueBeanBuilder.addTransitions(IssueBeanBuilder.java:138)
at com.atlassian.jira.rest.v2.issue.IssueBeanBuilder.build(IssueBeanBuilder.java:111)
at com.atlassian.jira.rest.v2.search.SearchResource$IssueToIssueBean.apply(SearchResource.java:278)
at com.google.common.collect.Lists$TransformingRandomAccessList.get(Lists.java:451)
....
Diagnosis
Affected versions of Fisheye seems to be versions 3.1 or newer.
Affected versions of JIRA are versions 6.1.7 or older. (JIRA 6.2 fixes the problem)
Cause
This is caused by - JRA-32132Getting issue details... STATUS , which throws an Internal Server Error when REST calls are made against issues with a workflow that has a looping transition, e.g. a transition where the destination step is the same step as the original status. In the workflow's XML, the transition's destination step has a ID of -1.
When a user clicks on a JIRA issue key in Fisheye, a REST call is fired to retrieve issue information, and as Fisheye 3.1 or newer now supports executing Transitions directly in Fisheye, the REST call will also retrieve all available workflow actions for that issue. This causes the nullPointerException when the workflow has the looping transition because the destination ID of -1 does not reflect any known step IDs.
Workaround
In JIRA 6.2, the workflow XML format has had some changes. The major change that fixed this problem is that it no longer uses a looping transition with step of -1. Importing a 6.1.x workflow into 6.2 will automatically re-map the workflow xml to reflect the new format.
Steps to workaround:
- Install a staging 6.2 instance.
- Import the problematic workflow XML into JIRA 6.2.
- Export the workflow from 6.2.
- Re-import it into current production instance.
Resolution
Upgrade to JIRA 6.2 or newer.