You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Attempting to parse an co.elastic.clients.elasticsearch._types.Script field in a response that is explicitly set to null (ie: the json payload specifically has "script": null in it) throws an JsonpMappingException.
Affected Versions:
At least 8.13.2 through the latest version (8.14.0) as of opening this ticket. I have not tested, nor intend to test, any prior versions to the one I am using.
Details:
A call to co.elastic.clients.elasticsearch.indices.ElasticsearchIndicesClient.getFieldMapping(GetFieldMappingRequest request) with the includeDefaults field of the GetFieldMappingRequest set to true produced the below redacted stacktrace. Setting includeDefaults in the request to its default value of false behaves as expected (aka: no exception thrown).
I wrote the following test to isolate the issue. When "script": null is explicitly present in a payload that would serialize to a FloatNumberProperty, the serialization throws the same JsonpMappingException. Removing the "script": null, entry in the below payload results in successful parsing with the script field in FloatNumberProperty (inherited from the NumberPropertyBase superclass) being defaulted to null, as expected.
Script._DESERIALIZER and potentially any other deserializers built from UnionDeserializer.Builder might throw a JsonpMappingException when attempting to serialize an explicit null entry in a payload if none of the elements in the union allow the VALUE_NULL jsonp event.
Any request that allows the same behavior that setting includeDefaults in GetFieldMappingRequest triggers could cause the same exception to be thrown if the response contains a null value that is deserialized using a deserializer described in the 1st conclusion.
The text was updated successfully, but these errors were encountered:
Hello, thank you for the detailed report. I have managed to reproduce the error, but I didn't understand the cause yet, since the same property is deserialized correctly in other union types (aggregations for example), we'll investigate this more.
Java API client version
8.13.2
Java version
17.0.11
Elasticsearch Version
8.3.2
Problem description
Executive Summary:
Attempting to parse an
co.elastic.clients.elasticsearch._types.Script
field in a response that is explicitly set tonull
(ie: the json payload specifically has"script": null
in it) throws anJsonpMappingException
.Affected Versions:
At least 8.13.2 through the latest version (8.14.0) as of opening this ticket. I have not tested, nor intend to test, any prior versions to the one I am using.
Details:
A call to
co.elastic.clients.elasticsearch.indices.ElasticsearchIndicesClient.getFieldMapping(GetFieldMappingRequest request)
with theincludeDefaults
field of theGetFieldMappingRequest
set totrue
produced the below redacted stacktrace. SettingincludeDefaults
in the request to its default value offalse
behaves as expected (aka: no exception thrown).I wrote the following test to isolate the issue. When
"script": null
is explicitly present in a payload that would serialize to aFloatNumberProperty
, the serialization throws the sameJsonpMappingException
. Removing the"script": null,
entry in the below payload results in successful parsing with thescript
field inFloatNumberProperty
(inherited from theNumberPropertyBase
superclass) being defaulted tonull
, as expected.From this I concluded that:
Script._DESERIALIZER
and potentially any other deserializers built fromUnionDeserializer.Builder
might throw aJsonpMappingException
when attempting to serialize an explicitnull
entry in a payload if none of the elements in the union allow theVALUE_NULL
jsonp event.includeDefaults
inGetFieldMappingRequest
triggers could cause the same exception to be thrown if the response contains a null value that is deserialized using a deserializer described in the 1st conclusion.The text was updated successfully, but these errors were encountered: