Concurrent project creation based on shared configuration results in all Issue Types within the project's Issue Type Scheme being unassigned

Issue Summary

Concurrent project creation based on shared configuration can result in all Issue Types within the project's Issue Type Scheme being removed.

It seems that the association itself remains (optionconfiguration), however, the link to that association is gone (fieldconfigschemeissuetype)

This may not have been introduced in 8.15.0, it was simply the version used to test

Steps to Reproduce

Testing environment: Jira 8.15.0, Postgres 9.6.20-1, single node DC

1. Create a SCRUM project named TEST
2. Under Jira Admin -> Issues -> Issue type schemes, observe the 5 Issue Types associated with "TEST: Scrum Issue Type Scheme"
3. Start concurrently creating projects based on Shared Configuration of project TEST
   1. This can be done via Java API, or, via createprojectbasedonsharedconfiguration HTTP resource
   2. Example for HTTP resource approach

      #!/bin/bash
      COUNTER=0
      while [ $COUNTER -lt 20 ]; do
          echo Created number $COUNTER
         curl -u admin:admin 'http://localhost:48150/j8150/rest/project-templates/1.0/createshared/10000' -H 'Accept: */*' -H 'Accept-Language: en-US,en;q=0.5' -H 'Content-Type: application/json' --data-raw "{\"key\":\"TEST${COUNTER}\",\"name\":\"TEST${COUNTER}\"}"  > /dev/null 2>&1 &
          echo 
          let COUNTER++
      done

   3. Partial snippet using JAVA API:

      ProjectManager projectManager = ComponentAccessor.getProjectManager();
      ProjectService projectService = ComponentAccessor.getComponent(ProjectService);
      
      final ProjectService.CreateProjectValidationResult result = projectService.validateCreateProjectBasedOnExistingProject();
      final Project newProject = projectService.createProject(result);
      

Expected Results

Projects are created, and the TEST:Scrum Issue Type Scheme lists the 5 Issue Types, along with assigned projects.

Database - Good (scheme ID 10400 is good)

select * from fieldconfigscheme where fieldid = 'issuetype'
<SNIP>
10400	"KAN: Kanban Issue Type Scheme"		"issuetype"	
10601	"TEST: Scrum Issue Type Scheme"		"issuetype"	

select * from fieldconfigschemeissuetype where fieldconfigscheme = 10400 
10502	NULL	10400	10400

select it.pname, oc.* from optionconfiguration oc  join issuetype it on oc.optionid = it.id where oc.fieldid = 'issuetype' AND oc.fieldconfig = 10400

"Epic"	10508	"issuetype"	"10000"	10400	4
"Task"	10504	"issuetype"	"10001"	10400	0
"Sub-task"	10505	"issuetype"	"10002"	10400	1
"Story"	10506	"issuetype"	"10100"	10400	2
"Bug"	10507	"issuetype"	"10101"	10400	3

Actual Results

Projects are created, however the 5 issue types under TEST: Scrum Issue Type Scheme are gone, replaced by No issue types associated

It is not possible to create new issues, as neither the project selector shows, nor the issue type list in order to create an issue.

Database - Broken (scheme id 10601 is broken)

select * from fieldconfigscheme where fieldid = 'issuetype'
<SNIP>
10400	"KAN: Kanban Issue Type Scheme"		"issuetype"	
10601	"TEST: Scrum Issue Type Scheme"		"issuetype"	

select * from fieldconfigschemeissuetype where fieldconfigscheme = 10601
[Empty Set]

select it.pname, oc.* from optionconfiguration oc  join issuetype it on oc.optionid = it.id where oc.fieldid = 'issuetype' AND oc.fieldconfig = 10601

"Epic"	10608	"issuetype"	"10000"	10601	4
"Task"	10604	"issuetype"	"10001"	10601	0
"Sub-task"	10605	"issuetype"	"10002"	10601	1
"Story"	10606	"issuetype"	"10100"	10601	2
"Bug"	10607	"issuetype"	"10101"	10601	3

The options are still there and associated, however, the scheme is missing it's fieldconfigschemeissuetype row.

Log files

The line below is repeated from a variety of sources. It appear to be whenever the "options" (issuetype assignments) are loaded by something:

java.lang.NullPointerException: config

    java.lang.NullPointerException: config
    	at java.base/java.util.Objects.requireNonNull(Objects.java:246) [?:?]
    	at com.atlassian.jira.issue.fields.option.CachedOptionSetManager.getOptionsForConfig(CachedOptionSetManager.java:51) [classes/:?]
    	at com.atlassian.jira.issue.fields.IssueTypeSystemField.getOptionsForConfig(IssueTypeSystemField.java:641) [classes/:?]
    	at com.atlassian.jira.issue.fields.IssueTypeSystemField.getOptionsForConfig(IssueTypeSystemField.java:637) [classes/:?]
    	at com.atlassian.jira.issue.fields.IssueTypeSystemField.getOptionsForIssue(IssueTypeSystemField.java:633) [classes/:?]
    	at com.atlassian.jira.issue.fields.IssueTypeSystemField.validateParams(IssueTypeSystemField.java:411) [classes/:?]
    	at com.atlassian.jira.quickedit.action.QuickCreateIssue.validateProjectAndIssueType(QuickCreateIssue.java:441) [?:?]
    	at com.atlassian.jira.quickedit.action.QuickCreateIssue.validateIssueTypeAndProject(QuickCreateIssue.java:430) [?:?]
    	at com.atlassian.jira.quickedit.action.QuickCreateIssue.doDefault(QuickCreateIssue.java:205) [?:?]
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [?:?]
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [?:?]
    	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [?:?]

Workaround

In the example above, it was possible to restore the issue type scheme association by:

1. Obtain the broken Issue Type Scheme ID with

   select * from fieldconfigscheme where fieldid = 'issuetype'

2. Verify the scheme is mising it's fieldconfigschemeissuetype association (0 rows) by

   select * from fieldconfigschemeissuetype where fieldconfigscheme = <ID> 

3. Verify the option assignments are still infact there:

   select it.pname, oc.* from optionconfiguration oc  join issuetype it on oc.optionid = it.id where oc.fieldid = 'issuetype' AND oc.fieldconfig = <ID>

4. Insert the missing row back into fieldconfigschemeissuetype table, then restart Jira. We will need to obtain a valid and unique id value, since this table's sequences are defined in-application, not by a database sequence (a database backup / staging instance could help here)