Cannot browse nor create Workflows due to Passed List had more than one value exception in Jira
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the server and data center platforms.
Summary
When the user navigate to the Workflows administration screen, no workflows are displayed, and the error below can be found in atlassian-jira.log:
2013-12-26 14:35:02,847 http-bio-8080-exec-19 ERROR sysadmin 875x161x1 ewvg6u 0:0:0:0:0:0:0:1%0 /secure/admin/workflows/ListWorkflows.jspa [webwork.util.ValueStack] query="inactiveWorkflows" {[id="inactiveWorkflows" type="8" values=""]}
java.lang.reflect.InvocationTargetException
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 webwork.util.InjectionUtils$DefaultInjectionImpl.invoke(InjectionUtils.java:70)
(...)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.IllegalArgumentException: Passed List had more than one value.
at org.ofbiz.core.entity.EntityUtil.getOnly(EntityUtil.java:62)
at com.atlassian.jira.workflow.DefaultWorkflowSchemeManager.getWorkflowScheme(DefaultWorkflowSchemeManager.java:175)
(...)
The error above is also displayed when trying to create a new workflow.
Environment
Any version of Jira Software Data Center and Server.
Any version of Jira Service Management Data Center and Server.
Cause
This error might be thrown when there is an inconsistency in the database in which more than one workflow scheme is associated to the same project.
Diagnosis
To identify which additional workflow schemes are associated to which projects, run the SQL query below, which will return the IDs of the affected projects and workflow schemes:
SELECT
na.source_node_id AS PROJECT,
na.sink_node_id AS WORKFLOW_SCHEME
FROM
nodeassociation na
WHERE
association_type = 'ProjectScheme'
AND sink_node_entity = 'WorkflowScheme'
AND na.source_node_id = (
SELECT
source_node_id as source_project
FROM
nodeassociation
WHERE
association_type = 'ProjectScheme'
AND sink_node_entity = 'WorkflowScheme'
GROUP BY source_node_id HAVING count(*) > 1
);Example output:
PROJECT WORKFLOW_SCHEME
---------- ---------------
53503 65700
53503 65701Resolution
Always back up your data before performing any modification to the database. If possible, try your modifications on a test server.
The solution consists of manually deleting the additional workflow schemes so that there is only one scheme associated per project.
The query below may help determining which Scheme is the best candidate for disassociation (based on whatever hint their names can give):
select
na.source_node_id as "Project Id",
p.pkey as "Project Key",
na.sink_node_id as "Workflow Scheme Id",
ws.name as "Workflow Scheme Name",
wse.id as "Workflow Scheme Entity Id",
wse.workflow as "Workflow Scheme Entity Workflow Name",
jw.id as "Workflow Id",
it.pname as "Issue Type Name (optional)"
from
nodeassociation na
join
project p on p.id = na.source_node_id
left join
workflowscheme ws on ws.id = na.sink_node_id
left join
workflowschemeentity wse on wse.scheme = ws.id
left join
issuetype it on it.id = wse.issuetype
left join
jiraworkflows jw on jw.workflowname = wse.workflow
where
na.association_type = 'ProjectScheme'
and na.sink_node_entity = 'WorkflowScheme'
and na.source_node_id = 53503 /* REPLACE BY THE "PROJECT" FROM THE DIAGNOSIS QUERY */
and na.sink_node_id in (65700, 65701); /* REPLACE BY THE "WORKFLOW_SCHEME" FROM THE DIAGNOSIS QUERY */Advised steps
You should first run this on a non-prod environment to validate the solution.
- Shut down Jira
Execute the DB command below to delete the Workflow Scheme ID which you would like to disassociate. The source_node_id should be the Project ID and the sink_node_id the Workflow Scheme ID (as an example, 53503 and 65700 were used):
DELETE FROM nodeassociation WHERE source_node_id = 53503 AND sink_node_id = 65700;Start Jira
It's always safer to perform DB deletions while the whole application's down (including all nodes in Data Center), but it may also work by performing the DB deletions then rolling restarting the nodes (restart one by one).
It's crucial you validate this behavior in a lower environment first. If you need to refresh a lower environment with data from the environment you're observing the issue, please refer to our Creating a test environment for Jira article.