[BUG] Unsupported ICU collation keyword field type

[paverman]

What is the bug?

Using of custom plugin-defined keyword field type icu_collation_keyword in the index mapping will lead to an error during response deserialization:

Missing Required Property Builder.<variant kind>

Can be reproduced by the following code:

index = "index_with_icu_collation_keyword"
GetMappingRequest getMappingsRequest = new GetMappingRequest.Builder().index(index).build();
response = client.indices().getMapping(getMappingsRequest);

Index mapping example:

{
    "mappings": {
        "_doc": {
            "dynamic": "strict",
            "properties": {
                "FIELD_NAME": {
                    "copy_to": [
                        "all"
                    ],
                    "store": true,
                    "type": "text",
                    "fields": {
                        "sort": {
                            "type": "icu_collation_keyword"
                        },
                        "keyword": {
                            "type": "keyword"
                        }
                    }
                }
            }
        }
    }
}

Seems like this is known issue and was fixed in elasticsearch-java sources as a part of this

Perhaps, this is a duplicate of #611 but with more specific details.

There is a possible workaround but it does not work with Apache HttpClient 5 Transport due to a different threads issue.

How can one reproduce the bug?

Use icu_collation_keyword in your index mapping.

What is the expected behavior?

The icu_collation field type should be deserialized without errors.

What is your host/environment?

Windows
OpenSearch Java Client 2.6.0
Java 11

[Bfindlay]

You can assgn this to me. I have a fix thats working locally, just need to spend some time writing more tests.

[paverman]

@Bfindlay Great, thank you.
Will this fix be included in next release 2.9.0? What is the approximate date for the next release? Can I find somewhere a build package from the main branch to test this fix without waiting for the release?

[Bfindlay]

@paverman not sure on releases, might have to check with one of the maintainers if there is a release scheduled soon.

[dblock]

Open a new issue that says "release v. next" and we'll take care of it.

[dblock]

Closed via #725