MissingRequiredPropertyException in PIT query

[floorleap]

Java API client version

8.17.0

Java version

17 (kotlin 2.0.x)

Elasticsearch Version

8.17.0

Problem description

Hi, I'm getting an exception when running a PIT request. The missing field is OpenPointInTimeResponse.shards. . Filing a bug as requested in the docs.

I initially posted in a different ticket. I was told there it is probably related to this recent change. The elasticsearch server should always send _shard in the response from version 8.16.0 forward.

Thanks!

The first error was caused by: node: https://localhost:50388/, status: 200, [es/open_point_in_time] Failed to decode response
co.elastic.clients.transport.TransportException: node: https://localhost:50388/, status: 200, [es/open_point_in_time] Failed to decode response
	at co.elastic.clients.transport.ElasticsearchTransportBase.decodeTransportResponse(ElasticsearchTransportBase.java:409)
	at co.elastic.clients.transport.ElasticsearchTransportBase.getApiResponse(ElasticsearchTransportBase.java:367)
	at co.elastic.clients.transport.ElasticsearchTransportBase.performRequest(ElasticsearchTransportBase.java:148)
	at co.elastic.clients.elasticsearch.ElasticsearchClient.openPointInTime(ElasticsearchClient.java:1809)
[...]

Caused by: co.elastic.clients.util.MissingRequiredPropertyException: Missing required property 'OpenPointInTimeResponse.shards'

cc @l-trotta

[l-trotta]

Hey!
Could you let me know how you are performing the OpenPointInTimeRequest? I just tried to reproduce the issue with a 8.17.0 server instance and it looks like the shards field is indeed always returned.

[matthewlowry]

I was seeing the same problem and it's because I was using the latest (8.17.0) client to talk to an older (8.15.0) cluster.

Downgrading the client to match the older cluster version fixed the problem.

This is a rather unfortunate lack of backwards compatibility here as I need to write tools that can talk to a fleet of clusters some of which are kept up-to-date (dev environment) and some which lag (prod environment).

I can work around this but still my preference is to keep our internal tooling in sync with the newer versions of Elasticsearch.

[l-trotta]

@matthewlowry unfortunately we cannot guarantee backwards compatibility, since our main goal is for the client to match the current server version as close as possible.

[floorleap]

@l-trotta thanks for getting back to me, I think I missed your reply due to the holidays.

I've not seen this error since, so I think it's resolved and perhaps our upgrade was not fully completed at the time I did my testing.