Two active Workflow Schemas in one project

Question

Hi.
My question is about non-correct REST API work in Jira Data Center v.9.12.
I have a problem with additing Workflow Scheme in project via POST /rest/api/2/project.

I have developed an application for easy project creation. The user selects the types of tasks he needs, and the application creates and configures all the necessary schemas. The application has been tested, and it fills in the schemas correctly, depending on the source data. But there was a problem with the assignment of the workflow schema.

The application's logic is as follows:
1. Before creating project, the necessary workflow scheme is created, based on the selected task types.
2. Then, the necessary WF Scheme id is passed through the command to create the project (as shown in the atlassian documentation for "Create project" -> "Request").
However, for some reason, Jira itself creates another default workflow schema at the time of project creation and additionally binds it to the project.

So there are two active WF Schemas in the system, which leads to critical errors in Jira itself - all workflow schemas are no longer displayed in the system and 500 errors appear.

The Jira log is like this:

Caused by: java.lang.IllegalArgumentException: Passed List had more than one value.

Also the log shows that at first step Jira correctly assign the necessary scheme but then creates and assign a new one too (with default issue types):

2026-08-12 09:08:28 … /rest/api/2/project [c.a.j.r.v2.issue.ProjectWorkflowSchemeAssignor] Assigning requestedWorkflowSchemeId=15755 into new project with projectId=15777

2026-08-12 09:08:28 … /rest/api/2/project [c.a.j.i.f.config.manager.FieldConfigSchemeManagerImpl] ConfigScheme TEST: Issue Type Scheme for tracking simple issues (17830). Created with no associated contexts

2026-08-12 09:08:28 … /rest/api/2/project [c.a.jira.workflow.OSWorkflowManager] User 'test.app(JIRAUSER42601)' updated workflow 'TEST: Workflow Scheme for tracking simple issues.' at 'Wed Aug 12 09:08:28 UTC 2026'

2026-08-12 09:08:29 … /rest/api/2/issuetypescheme [c.a.j.i.f.config.manager.FieldConfigSchemeManagerImpl] ConfigScheme TEST Issue Scheme (17831). Created with no associated contexts

2026-08-12 09:08:33 … /rest/api/2/status [c.a.j.rest.exception.ExceptionInterceptor] Returning internal server error in response

java.lang.reflect.InvocationTargetException

at jdk.internal.reflect.GeneratedMethodAccessor4578.invoke(Unknown Source)

…

at java.base/java.lang.Thread.run(Thread.java:840)

Caused by: java.lang.IllegalArgumentException: Passed List had more than one value.

And finally I have two active schemes: my with id=15755 and Jira with id=15756.

How and why did this happen?

Mohammad Mahyar ahmadi · Answer

Hi Евгения, A follow-up to my answer above, because my test instance just showed the duplicate I couldn't confirm there. A few days after that test I added a post function to a completely different workflow on the same instance and got a 500 page with the same exception you had: IllegalArgumentException: Passed List had more than one value, coming from DefaultWorkflowSchemeManager.getSchemeForProject. The post function was saved, the error came after the save. So I read the scheme associations straight from NodeAssociation (Project -> WorkflowScheme, type ProjectScheme). The project I had created with workflowSchemeId had two workflow schemes on it: the one I sent, plus "{KEY}: Simple Issue Tracking Workflow Scheme" that Jira had created on its own. It was the only project on the instance with more than one. So on 9.6 it's the same duplicate you described, not only a broken /statuses. And it doesn't stay inside that project - in my case it was a save on another workflow that ended in that 500. This lists every project in that state, read-only (ScriptRunner console): import com.atlassian.jira.component.ComponentAccessor import org.ofbiz.core.entity.GenericValue def pm = ComponentAccessor.projectManager def rows = ComponentAccessor.ofBizDelegator.findByAnd("NodeAssociation", [sourceNodeEntity: "Project", sinkNodeEntity: "WorkflowScheme", associationType: "ProjectScheme"]) def byProject = rows.groupBy { GenericValue gv -> gv.getLong("sourceNodeId") } def broken = byProject.findAll { Long pid, List list -> list.size() > 1 } return "rows " + rows.size() + ", projects " + byProject.size() + ", broken: " + broken.collect { Long pid, List list -> pm.getProjectObj(pid)?.key + ": " + list.collect { GenericValue gv -> gv.getLong("sinkNodeId") } } And this is the same thing I did to clean it up, with the key and ID pulled out as variables: keep the scheme you meant to use, drop the extra association. My test project had no issues, so there was nothing to migrate. If yours already have issues, check which workflow they're on first, and try it on a staging copy before production. import com.atlassian.jira.component.ComponentAccessor import org.ofbiz.core.entity.GenericValue def projectKey = "ABC" // the broken project def keepSchemeId = 10000L // the workflow scheme it should keep def project = ComponentAccessor.projectManager.getProjectObjByKey(projectKey) def wsm = ComponentAccessor.workflowSchemeManager def ofbiz = ComponentAccessor.ofBizDelegator def query = [sourceNodeId: project.id, sourceNodeEntity: "Project", sinkNodeEntity: "WorkflowScheme", associationType: "ProjectScheme"] def before = ofbiz.findByAnd("NodeAssociation", query).collect { GenericValue gv -> gv.getLong("sinkNodeId") } if (before.size() > 1 && before.contains(keepSchemeId)) { wsm.removeSchemesFromProject(project) wsm.addSchemeToProject(project, wsm.getSchemeObject(keepSchemeId)) wsm.clearWorkflowCache() } def after = ofbiz.findByAnd("NodeAssociation", query).collect { GenericValue gv -> gv.getLong("sinkNodeId") } return "before: " + before + ", after: " + after After that the first script came back empty, and editing that other workflow again went through without the error. Hope that helps.

Mohammad Mahyar ahmadi · Answer

Hi Евгения,

Adding to James's answer - I ran a version of his isolation test on my own Data Center instance, with a control project next to it. Mine is 9.6.0, not 9.12, so keep that in mind.

First, a small correction on the field name, in case someone copies it from this thread: on DC it's workflowSchemeId. That's what the Create project example in the REST docs for 9.6 and 9.12 uses, and the same docs list a 409 for when the requested scheme can't be assigned. workflowScheme gets rejected on my 9.6:

400 Unrecognized field "workflowScheme" (Class com.atlassian.jira.rest.v2.issue.project.ProjectInputBean), not marked as ignorable

Same 400 for workflowSchemeKey. JRASERVER-59948 writes it as workflowScheme in its table, so that name is floating around, but it's not the one the endpoint takes. Your log shows requestedWorkflowSchemeId being assigned, so what you send is clearly being accepted - this is more for whoever reads this later.

Now the test. Two projects on the same instance, a few minutes apart, same body apart from the key and name - one with workflowSchemeId, one without. No other calls on either of them before the check. Then:

GET /rest/api/2/project/{projectKey}/statuses

3 existing normal projects             -> 200
project created without the field      -> 200
project created with workflowSchemeId  -> 500

So on 9.6, one isolated create call with the documented field is enough to leave the project broken. That's close to the case James describes in his last paragraph. From the /statuses result alone I can't tell whether a second scheme was created on mine, so I won't claim it's the same duplicate, but I'd take this to Atlassian Support with your logs rather than keep digging in the app.

Two caveats though. I don't have the server log on that instance, so I can't show the exception behind that 500 or confirm it's the same "Passed List had more than one value" you got. And the POST status codes weren't reliable for me: the control project came back with 500 but was created and healthy, while the broken one came back with 201. That's why I'm comparing the end state of the projects and not the create responses.

For now I'd create the project without workflowSchemeId and set the scheme as a separate step. The catch is I couldn't find a public REST endpoint on DC for that step. GET /rest/api/2/project/{projectKeyOrId}/workflowscheme only reads (handy for James's check though - it shows which scheme the project ended up with), and /rest/api/2/workflowscheme/project returns 404 on my instance. If anyone knows a supported way to assign a workflow scheme to an existing project from REST on DC, I'd like to hear it too.

Hope that helps.

Евгения Иволга · Answer

Thanks for the reply, James!

Yes, I'll try to test the app only with the POST /rest/api/2/project request and see how the system behaves.