Concurrent modification of single issue might result with stale values of its fields in index

Issue Summary

This is reproducible on Data Center: (yes)

Root cause here is that issue document is built basing on information stored, for some system fields and custom fields, in thread local caches, that are populated on first read and not reloaded unless they are updated within the same thread. 

Known examples of fields that might be affected:

• subtask parent during subtask creation (the parent field of the newly created sub-task might not be indexed correctly, and as a result the sub-task might not show in the Active Sprint page)
• any custom field of date/text type during issue update or creation

Automated operations triggered by issue update events(executed threads parallel than the Issue update thread) might increase frequency of this happening, but in theory all concurrent operations on single issue might be affected.

Steps to Reproduce

1. Prepare a project with issues configured to contain at least one simple(text or date type) custom field - cf1
2. Create a plugin that performs the following operations on some trigger(rest endpoint, automation)
   1. operation 1: 
      1. Reads value of cf1 for particular issue issue1
      2. Consider introducing some sleep here or some debug pause
      3. Eventually reindexes issue1
   2. operation 2, triggered separately:
      1. update value of cf1 in issue1
      2. reindex issue1
3. Trigger operation1 and operation 2 in a way that operation2 starts after pt 2.1.1 and ends before pt 2.1.3

Expected Results

JQL searches by value set to cf1 in issue1 in pt 2.2.1 return issue1

Actual Results

JQL searches by value set to cf1 in issue1 in pt 2.2.1 do not return issue1

Workaround

Currently there is no known workaround for this behaviour. A workaround will be added here when available