Internal Server Error (NullPointerException) when clicking on JIRA issue keys in Fisheye

Still need help?

The Atlassian Community is here for you.

Ask the community

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-32132 - Getting 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:

  1. Install a staging 6.2 instance.
  2. Import the problematic workflow XML into JIRA 6.2.
  3. Export the workflow from 6.2.
  4. Re-import it into current production instance.

Resolution

  • Upgrade to JIRA 6.2 or newer.

Last modified on Jul 31, 2018

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.