Examinex not always send mapping to create index

[bielu]

Describe the bug I noticed my index mapping is not alway correctly send to azure search, i noticed that on specific fields where it gets submitted as string collection not as mapped in FieldDefinitions as int64! it happens when using with umbraco

License ID Your ExamineX license Id (found in your license file) 5f2da131-2ba2-49ca-a7ba-a4d0eb087469

To Reproduce Steps to reproduce the behavior: make umbraco with around 3-4k nodes with block grid and around 10-15 properties, try rebuild index with umbraco built-in feature to rebuild index.

Expected behavior Index mapping is always correctly submited.

Screenshots If applicable, add screenshots to help explain your problem.

Versions

• ExamineX version 6.0.1
• Umbraco version 13.2.2
• Examine version 3.2

Additional context It not always happens and it is really hard to figure out what triggers it, but noticed it is more often happen if in time when umbraco rebuilds first batch happens any publish...

[Shazwazza]

Thanks for the report @bielu,

Are the field types you are referring to custom fields/mappings? Or is this based on the field types defined by Umbraco?

If custom fields, how are you creating these, are you creating them using LuceneDirectoryIndexOptions or explicitly using AzureSearchIndexOptions?

[bielu]

I use AzureSearchIndexOptions with IPostConfigureOptions and it works most of times. and when debugging I always see correct mappings. I think it is related to lack of Index existance on indexing and creating index based on current document (automatic azure mapping?)

[Shazwazza]

So the String Collection types are used when ExamineX can't determine an explicit type specified for the field. Its not the default for Azure Search, but is the default for ExamineX.

You could try debugging/logging in the CreatingOrUpdatingIndex event to see when the field(s) you are expecting to be of a certain type are not and can potentially see if there's any descrepencies with the casing of any field names.

I'm wondering if it could be related to a dictionary being used that is case sensitive and one of the aliases of a field defined between doc types is the same but has a different casing.

[bielu]

The case sensitivity is not really an option as we create this field by hand based on constant. I will try add some logging with events and see if I can give you some info, but it will be post code garden

[Shazwazza]

I've just pushed version 6.0.3 which addresses a few dictionaries that were not created with case insensitivity. This potentially could resolve the issue for you since I can see in the code that if there was case sensitivity issues, it could pose this type of problem.