`TermQueryConverter` is failing to deserialize string value

[MikeAlhayek]

Elastic.Clients.Elasticsearch version:
8.16.3

Elasticsearch version:
8.6.1

.NET runtime version:
.net9

Description of the problem including expected versus actual behavior:

I am trying to deserialize the following query:

{
  "query": {
    "term": { "Content.ContentItem.ContentType": "BlogPost" }
  },
  "size": 3
}

This query string is being deserialized using the SourceSerializer like this:

using var stream = new MemoryStream(Encoding.UTF8.GetBytes(query));
var request = _client.SourceSerializer.Deserialize<SearchRequest>(stream);

However, the code above fails to deserialize the value of the term query when it is provided as a string.

The following query works as expected:

{
  "query": {
    "term": { "Content.ContentItem.ContentType": { "value": "BlogPost" } }
  },
  "size": 3
}

Steps to reproduce:

1. Try to deserialize the query listed above using the code.

Expected behavior
I expect that the value will be deserialize from a string or from an object.

[flobernd]

Hi @MikeAlhayek,

this is not considered a bug as we do not guarantee that all types are round-trip serializable.

Especially request-only types might only implement serialization while response-only types only implement deserialization. Some types implement both operations.

For TermQuery, indeed both implementations exist, but the "shortcut" form (string instead of object) is not supported as this form never occurs when using the client to build queries.

That being said, I'm currently working on improvements to the serialization code as a requirement for a different feature. As part of these improvements, it will be possible to handle the shortcut form.

PS: Please use the RequestResponseSerializer instead of the SourceSerializer 🙂

PS2: The Elastic.Transport namespace provides some useful extensions to e.g. directly deserialize from a string. This saves you the MemoryStream and Encoding.GetBytes overhead.

[MikeAlhayek]

@flobernd thank you for your quick response.

this is not considered a bug as we do not guarantee that all types are round-trip serializable.
Understood. Since there is a built in serialize, it would be nice to support "shorthand".

PS: Please use the RequestResponseSerializer instead of the SourceSerializer 🙂

Done. With the same result (but I think you expected that too).

PS2: The Elastic.Transport namespace provides some useful extensions to e.g. directly deserialize from a string. This saves you the MemoryStream and Encoding.GetBytes overhead.

Does the Elastic.Transport support "shorthand"?

If nothing here supports the shorthand query, is there a workaround to add this support for my project while continue to using RequestResponseSerializer?

[MikeAlhayek]

I ended up using Transport and directly query the server from string.

Thanks for your help.

[flobernd]

Done. With the same result (but I think you expected that too).

Yes, this functionality will only be available when the new serialization logic is released (early next year).

I ended up using Transport and directly query the server from string.

This is a good workaround, especially for your use-case that involves raw string queries!