[BUG] Max aggregation result is defaulted 0 when there is no value from OpenSearch

[tnguyen456]

What is the bug?

MaxAggregate has value as 0 when there is no record match or aggregated field has no values even though OpenSearch returns null

How can one reproduce the bug?

• Create an index with a numeric field
• Send aggregation request for the field
• Since there is no document, the aggregation result is returned as null by OpenSearch but MaxAggregate from java-client has value as 0

What is the expected behavior?

Because value is defaulted to 0, it causes confusion to consumers as there is no way to tell whether 0 means no value or it's actually the max.

The expected behaviour should be returning the same value as OpenSearch

What is your host/environment?

OpenSearch 2.11
OpenSearch java client 2.14

[Xtansia]

Hi @tnguyen456,

Thanks for raising this issue, you definitely make a great point regarding differentiate missing values and true zero.
I'll need to do a little code archaeology to see if I can discern the original reasoning for the behaviour incase it is relevant.
As changing this behaviour would be a breaking change it may not be fixed until the 3.0.0 release, otherwise it would need a backwards compatible change that adds an additional getter (e.g. valueOrNull) with the correct behaviour and the old getter keeps the defaulting logic.

[Xtansia]

And if you're interested in raising a PR to make such a fix yourself, it would be greatly welcomed.

[tnguyen456]

Thanks @Xtansia for quick response.

We've implemented a kinda hacky workaround to override the deserializer to make it work for our cases.

But yeah, I agree that the proper fix should be like what you mentioned.

Probably I will try to come up with an PR.

[tnguyen456]

Hi @Xtansia , just want to confirm a few things before opening a PR for this:

• When would be 3.0.0 released and which OS version would it be compatible with?
• If we have another getter , so called valueOrNull, to make it compatible with 2.x, would you see it permanent or we will do another clean up in 3.0.0 to remove the new getter and make value nullable (as a breaking change of course). I personally prefer to only have value which is nullable.

Thanks.

[Xtansia]

@tnguyen456 I expect the 3.0.0 release to generally align with the OpenSearch core/server 3.0.0 release (roughly end of April / beginning May), but it does not have a fixed date. It should broadly remain compatible with OS 1.0 through to 3.x.

I would only do the valueOrNull style fix purely as a backwards compatible fix just for 2.x but do only the breaking change (nullable value) for 3.0.0, so the valueOrNull wouldn't exist in 3.0.0.

[Xtansia]

This fix was included in the client's v3.0.0 release