Client cannot deserialize string to list of strings

[matteocalisti]

Elastic.Clients.Elasticsearch version: 8.13.12

Elasticsearch version: 8.13.2

.NET runtime version: net6.0

Operating system version: Windows 10

Description of the problem including expected versus actual behavior:
Using timeseries mode on a backing index of a datastream serializes a list of strings with a single string as an individual string, not as an array of strings. The client fails to deserialize the source document because of this.

Steps to reproduce:

1. Clone this example repo
2. Change the field elasticsearchAddress in both test classes to point to a 8.13.x instance of Elasticsearch
3. Execute tests: 3 of them are ok, 1 fails

Expected behavior
Elasticsearch serializes a list of string as an individual string, the client should be able to deserialize the single string to the original C# type (a list of strings) with a single string.

Is the mapping correct for this type of scenario?

[flobernd]

Hi @matteocalisti,

I sadly can't help you with the mapping question. You will probably find somebody in the community forums who is able to answer your question. It might be that a different mapping causes ES to always send the value as an array which would then solve your issue.

Otherwise, source (de-)serialization is completely customizable by the user. By default, our deserializer is "stupid". The plain JSON is deserialized "as is". You might want to have a look at the SingleOrManyCollectionConverter for inspiration. This is how we solve a similar problem internally.

Please let me know, if you need further assistance.

[matteocalisti]

Thank you for your answer, flobernd.

I will look into writing a custom deserializer and will let you know if I succeed this way!

[matteocalisti]

Just tested, marking the property with SingleOrManyCollectionConverterAttribute corrects the serialization. Many thanks!

At the moment I have copied all code of the attribute and related classes, is it possible to make the attribute public? Or is it supposed to be only for internal use?

[flobernd]

Glad I was able to help 🙂 Closing this issue now.

I'd rather not expose the attribute as it's only used on internal request/response data-types. The functionality might have to be adjusted at some point and that would potentially break user code in this case. But feel free to copy/paste it!