Very strange behavior of index templates

[abaxanean]

1. Have an index template which matches everything and defines under mappings a "default" type with some "dynamic_templates", e.g.

   {
   "template_parent": {
     "mapping": {
       "include_in_all": false,
       "index": "not_analyzed"
     },
   "match": "parent_*"
   }
   }
   

   Indices, types and their mappings are supposed to be generated dynamically, considering the template.
2. Index items in parallel from multiple threads on multiple indices (one type per index).

Observed : Indices are dynamically generated but the mapping lack from some of them.
e.g Items of type 'A' indexed on index 'a' led to the creation of index 'a', the creation of type 'A' on this index, and properties that starts with 'parent_' not being analyzed.
On the other hand, Item Type 'B' which must have been generated on index 'b' isn't there at all, the documents themselves are there (/B/_count returns the correct number, /B/b/_count returns 0). The index metadata returned(b/_mapping) also reveals that there is no type 'B' on the index, only the 'default' type. The documents listed via /b/_search have their type attribute equals to 'B'.

Everything is done from Java Client.
Start node, put template, insert items in parallel.

[abaxanean]

I switched to using default-mapping.json (having the 'default' type with 'dynamic_templates' within it).
Anyway, It happens sometimes that, having documents in an index, the index mapping is empty (I mean empty at all "mappings": {})Performing search on such an index leads to error logs with debug level (e.g. sort by a nonexistent column).

[javanna]

Hi @bax1989, can you reproduce this issue? It would be great if you can attach a complete recreation to the issue so that we can reproduce it and understand what causes it.

[abaxanean]

I can't give you a concrete scenario since it's a concurrency issue as it seems and does not get reproduced constantly.

[clintongormley]

Hi @bax1989

If you're still seeing this issue, then it should be fixed by #8688