GenericTransactionException: Commit failed, rollback previously requested by nested transaction.

A change made in the behavior of JIRA API since JIRA 7.0 in relation with issue transition is causing an exception when trying to execute a "relative issue" using virtual fields "Execute transition (delayed execution)" or "Issue status (delayed execution)" and a condition or validator prevents the issue to be transitioned.

Relative issues are those with a relation parent-subtask or epic-story.

Example: when a parent issue is being transitioned by a child issue (relations parent-subtask and epic-story), if the child issue tries to execute a transition in the parent issue and it fails due to a condition or validation not satisfied in the parent issue, the transition will fail because the two transitions are being treated as a unique transaction. This problem also happens when the parent issue tries to execute a transition on its children issues.

The exception looks like this in the log file:

2016-02-22 13:31:51,313 http-nio-8080-exec-18 ERROR admin 811x2534x1 1yc3u2m 0:0:0:0:0:0:0:1 /secure/WorkflowUIDispatcher.jspa [c.a.jira.transaction.TransactionSupportImpl] Unable to commit transaction : Commit failed, rollback previously requested by nested transaction.
org.ofbiz.core.entity.GenericTransactionException: Commit failed, rollback previously requested by nested transaction.
    at org.ofbiz.core.entity.TransactionUtil.commitLocalTransaction(TransactionUtil.java:342)
    at com.atlassian.core.ofbiz.util.CoreTransactionUtil.commit(CoreTransactionUtil.java:41)
    at com.atlassian.jira.transaction.TransactionSupportImpl$TransactionImpl.commit(TransactionSupportImpl.java:76)
    at com.atlassian.jira.workflow.OSWorkflowManager.doWorkflowActionInsideTxn(OSWorkflowManager.java:832)
    at com.atlassian.jira.workflow.OSWorkflowManager.doWorkflowAction(OSWorkflowManager.java:786)
    at com.atlassian.jira.bc.issue.DefaultIssueService.transition(DefaultIssueService.java:430)
    at com.atlassian.jira.web.action.workflow.SimpleWorkflowAction.doExecute(SimpleWorkflowAction.java:28)
    ... 1 filtered
    at com.atlassian.jira.action.JiraActionSupport.execute(JiraActionSupport.java:63)
    ... 7 filtered
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
    ... 50 filtered
    at com.atlassian.greenhopper.jira.filters.ClassicBoardRouter.doFilter(ClassicBoardRouter.java:59)
    ... 27 filtered
    at com.atlassian.labs.httpservice.resource.ResourceFilter.doFilter(ResourceFilter.java:59)
    ... 75 filtered
    at com.atlassian.fastdev.AutoReloadFilter.doFilter(AutoReloadFilter.java:63)
    ... 55 filtered
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:745)

A workaround to avoid this problem is using "Filtering by field values" parameter in "Write field on linked issues or subtasks" and "Write field on issues returned by JQL query" post-functions , or conditional operator ? : in "Copy a parsed text to a field" in order to pre-validate that the conditions and validations in the issue to be transitioned are going to be satisfied, and this way ensure that we won't attempt a transition until we are sure that it will be successful.

For the moment, recipes in the documentation site of the plugin involving linked issues, subtasks and paren issue transition have been modified to explain this workaround.

Comments (4)