Sub-tasks are not Correctly Associated with Parent Issues in Jira

Related content

  • No related content found

Still need help?

The Atlassian Community is here for you.

Ask the community

Symptoms

  1. In Task Board, all issues are displayed in 'Other Issues' section, no matter whether they have sub-tasks or not. The sub-tasks are not correctly populated and associated with parent issues.
  2. When accessing the Task Board, the below exception is generated.
  3. Attempting to close a Sprint.

The following appears in the atlassian-jira.log and also on the Task Board:

2012-10-15 15:41:05,621 http-8080-10 WARN admin 941x516x1 1jrx0ci 127.0.0.1 /secure/TaskBoard.jspa [greenhopper.jira.boards.TaskBoard] java.lang.NullPointerException
java.lang.NullPointerException
	at com.pyxis.greenhopper.jira.boards.TaskBoard.getParentIssueKeys(TaskBoard.java:179)
	at com.pyxis.greenhopper.jira.boards.TaskBoard.getParentBoards(TaskBoard.java:137)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:142)
	at org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:525)
	at org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:198)
	at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:262)
	at org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:507)
	at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:155)
	at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:262)
	at org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:507)
	at org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71)
	at org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142)
	at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
	at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336)
	at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:106)
	at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336)
	at org.apache.velocity.Template.merge(Template.java:328)
	at org.apache.velocity.Template.merge(Template.java:235)

Also the following variation of the error can be seen on the atlassian-jira.log.

http-nio-8016-exec-2 ERROR admin 1007x11797138x3 152eqow 10.255.172.131,10.197.8.40 /rest/greenhopper/1.0/sprint/21821/complete [c.a.p.r.c.error.jersey.ThrowableExceptionMapper] Uncaught exception thrown by REST service: null
 java.lang.NullPointerException
 at com.atlassian.greenhopper.web.rapid.sprint.SprintStatusChangeHelper.getParentsWithUnfinishedSubtasks(SprintStatusChangeHelper.java:263)
 at com.atlassian.greenhopper.web.rapid.sprint.SprintStatusChangeHelper.getCompleteSprintStatistics(SprintStatusChangeHelper.java:122)
 at com.atlassian.greenhopper.web.rapid.sprint.CompleteSprintResource.buildCompleteModel(CompleteSprintResource.java:118)
 at com.atlassian.greenhopper.web.rapid.sprint.CompleteSprintResource.getCompleteModel(CompleteSprintResource.java:101)
 at sun.reflect.GeneratedMethodAccessor17965.invoke(Unknown Source)
 ... 1 filtered
 at java.lang.reflect.Method.invoke(Method.java:498)
 ... 18 filtered
 at com.atlassian.plugins.rest.module.RestDelegatingServletFilter$JerseyOsgiServletContainer.doFilter(RestDelegatingServletFilter.java:154)
 ... 1 filtered
 at com.atlassian.plugins.rest.module.RestDelegatingServletFilter.doFilter(RestDelegatingServletFilter.java:68)
 ... 32 filtered
 at com.atlassian.servicedesk.internal.web.ExternalCustomerLockoutFilter.doFilter(ExternalCustomerLockoutFilter.java:56)
 ... 13 filtered
 at com.atlassian.web.servlet.plugin.request.RedirectInterceptingFilter.doFilter(RedirectInterceptingFilter.java:21)
 ... 49 filtered
 at com.atlassian.jira.security.JiraSecurityFilter.lambda$doFilter$0(JiraSecurityFilter.java:66)
 ... 1 filtered
 at com.atlassian.jira.security.JiraSecurityFilter.doFilter(JiraSecurityFilter.java:64)
 ... 16 filtered
 at com.atlassian.plugins.rest.module.servlet.RestSeraphFilter.doFilter(RestSeraphFilter.java:37)
 ... 19 filtered
 at com.atlassian.jira.servermetrics.CorrelationIdPopulatorFilter.doFilter(CorrelationIdPopulatorFilter.java:30)
 ... 5 filtered

Cause

The Jira issue is a sub-task that is not correctly associated with its parent issue. As JIRA currently does not support database transaction, there is a possibility that the database connection failure in the master issue deleting transaction may have caused the sub-task to be left as an orphan. We suspect that this problem may be caused by the specific operation of workflow or issue type migration. However, so far we still cannot reproduce the problem.

Another possible cause for this is using 3rd party apps/plugins to create issues during workflow transitions. Check for the app's versions in the Marketplace and lookout for bug fixes that may be related to this behavior.

Solution

Fixing broken records (integrity checker)

  1. Execute the Jira database integrity checker.
  2. Focus on the first section named "Check Issue Relations".
  3. If it finds any errors, choose to fix them.
  4. Re-index the affected project or re-index the whole instance (doing background or foreground re-index).

If the integrity checker did not find any issues, proceed to the alternate method below.

Fixing broken records (alternate method)

  1. Identify problematic records with the below SQL:

    j.id is the orphaned sub-task's ID within the JIRA database, a unique identifier; p.pkey is the Project Key for the orphaned sub-task; j.issuenum is the orphaned sub-task's number within its project

    Expand for PostgreSQL
    PostgreSQL 
    SELECT j.id, p.pkey||'-'||j.issuenum as "Issue Key"
 FROM jiraissue j, issuetype i, project p
 WHERE j.issuetype=i.id
 AND j.project = p.id
 AND i.pstyle='jira_subtask'
 AND j.id not in
  (SELECT l.destination
   FROM issuelink l, issuelinktype t
   WHERE l.linktype = t.id
   AND t.linkname='jira_subtask_link');
    Expand for MySQL
    MySQL 
    SELECT j.id, CONCAT(p.pkey,'-', j.issuenum) as "Issue Key" 
FROM jiraissue j, issuetype i, project p 
WHERE j.issuetype=i.id AND j.project = p.id 
AND i.pstyle='jira_subtask' 
AND j.id not in 
  (SELECT l.destination
  FROM issuelink l, issuelinktype t  
  WHERE l.linktype = t.id 
  AND t.linkname='jira_subtask_link');
    Expand if the queries above fail... 
    SELECT j.id, p.pkey, j.issuenum
 FROM jiraissue j, issuetype i, project p
 WHERE j.issuetype=i.id
 AND j.project = p.id
 AND i.pstyle='jira_subtask'
 AND j.id not in
  (SELECT l.destination
   FROM issuelink l, issuelinktype t
   WHERE l.linktype = t.id
   AND t.linkname='jira_subtask_link');
  2. Execute one of the following options:
    1. Review those orphan sub-tasks and delete them in Jira.
    2. As in our Moving an Issue, migrate them to another Issue Type.

Fixing the root cause

  1. Ensure that the Surviving Connection Closures documentation has been followed to prevent the connection to the database from closing.
  2. Review the associated issue's workflows (and the possible parent's workflows) and look for 3rd party apps post-functions that may create issues during transition. Try moving the post-function's execution order or upgrading the 3rd party app.


Last modified on May 5, 2021

Was this helpful?

Yes
No
Provide feedback about this article

Related content

  • No related content found
Powered by Confluence and Scroll Viewport.