Regression Bug: Char Filter requires mappings field even when mappings_path is used

[moritzluedtke]

Java API client version

8.2.2

Java version

Kotlin 1.70

Elasticsearch Version

8.2.2

Problem description

When creating our index through the new Elasticsearch Java Api Client (8.2.2) we discovered that we can't create a Char Filter that only has the field mappings_path set. The field mappings seems to be mandatory although mappings_path is set. In our old version with the old Rest-High-Level-Client this was possible and should be possible again.

This is how we read the json config in our kotlin class:

val configAsJson = Json.parseToJsonElement(ourIndexConfigAsJsonString).jsonObject
esClient.indices().create { indexCreateBuilder ->
    indexCreateBuilder
        .index(indexNameService.createInternalIndexName(tenant, esConfig.indexBaseName))
        .mappings { it.withJson(StringReader(configAsJson["mappings"].toString())) }
        .settings { it.withJson(StringReader(configAsJson["settings"].toString())) }
}

Only this json config is accepted:

"char_filter": {
    "multi_char_filter": {
        "type": "mapping",
        "mappings": [
            "xyz => xyz"
        ],
        "mappings_path": "analysis/multi-char-replacement.txt"
    }
}

When we remove the mappings portion we get the following error:

co.elastic.clients.json.JsonpMappingException: Error deserializing co.elastic.clients.elasticsearch._types.analysis.CharFilterDefinition: co.elastic.clients.util.MissingRequiredPropertyException: Missing required property 'MappingCharFilter.mappings' (JSON path: analysis.char_filter.multi_char_filter) (line no=1, column no=780, offset=779)
	at co.elastic.clients.json.JsonpMappingException.from0(JsonpMappingException.java:134)
	at co.elastic.clients.json.JsonpMappingException.from(JsonpMappingException.java:121)
	at co.elastic.clients.json.ObjectDeserializer.deserialize(ObjectDeserializer.java:206)
	at co.elastic.clients.json.ObjectDeserializer.deserialize(ObjectDeserializer.java:136)
	at co.elastic.clients.json.BuildFunctionDeserializer.deserialize(BuildFunctionDeserializer.java:53)
	at co.elastic.clients.json.DelegatingDeserializer$SameType.deserialize(DelegatingDeserializer.java:48)
	at co.elastic.clients.json.UnionDeserializer$SingleMemberHandler.deserialize(UnionDeserializer.java:74)
	at co.elastic.clients.json.UnionDeserializer.deserialize(UnionDeserializer.java:291)
	at co.elastic.clients.json.UnionDeserializer.deserialize(UnionDeserializer.java:258)
	at co.elastic.clients.json.DelegatingDeserializer$SameType.deserialize(DelegatingDeserializer.java:43)
	at co.elastic.clients.json.JsonpDeserializerBase$StringMapDeserializer.deserialize(JsonpDeserializerBase.java:347)
	at co.elastic.clients.json.JsonpDeserializerBase$StringMapDeserializer.deserialize(JsonpDeserializerBase.java:331)
	at co.elastic.clients.json.JsonpDeserializer.deserialize(JsonpDeserializer.java:75)
	at co.elastic.clients.json.ObjectDeserializer$FieldObjectDeserializer.deserialize(ObjectDeserializer.java:71)
	at co.elastic.clients.json.ObjectDeserializer.deserialize(ObjectDeserializer.java:180)
	at co.elastic.clients.json.ObjectDeserializer.deserialize(ObjectDeserializer.java:136)
	at co.elastic.clients.json.JsonpDeserializer.deserialize(JsonpDeserializer.java:75)
	at co.elastic.clients.json.ObjectBuilderDeserializer.deserialize(ObjectBuilderDeserializer.java:79)
	at co.elastic.clients.json.DelegatingDeserializer$SameType.deserialize(DelegatingDeserializer.java:43)
	at co.elastic.clients.json.ObjectDeserializer$FieldObjectDeserializer.deserialize(ObjectDeserializer.java:71)
	at co.elastic.clients.json.ObjectDeserializer.deserialize(ObjectDeserializer.java:180)
	at co.elastic.clients.util.WithJsonObjectBuilderBase.withJson(WithJsonObjectBuilderBase.java:66)
	at co.elastic.clients.json.WithJson.withJson(WithJson.java:57)
	at de.company.ourProduct.EsOperations.createIndex$lambda-2$lambda-1(EsOperations.kt:132)

...

[swallez]

Thanks for reporting this. It's an issue in the API specification used to produce the Java code where mapping should be optional. Once the API specification is fixed, the Java client code will be updated to resolve this issue.

In the meantime, a workaround is to set a dummy mapping as you did: mappings_path has precedence over mappings and will be used if present.

[moritzluedtke]

Thanks @swallez. Can you predict when the new version of the client gets released?

[swallez]

@moritzluedtke version 8.3.3 should be released at the end of this month. In the meantime you can also use the snapshot version 8.3.3-SNAPSHOT that should be available tomorrow or in the next few days from the https://snapshots.elastic.co/maven/ repo.