Add EvaluationReason.VALUE_ROUNDED for intVariation rounding a double value use case

[lirannesta]

Hi,

When invoking the client's intVariation for a flag with a double variation returned value, the returned value's fractional part is being rounded to zero.

This is consistent with the documentation of intVariation method:
intVariation inside the 'LDClient' class.

We , as clients would like to be able to detect such case , as it can cause bugs.

We have not found any way to have this situation detected easily using the SDK.

It would be helpful if we could detect this case by inspecting the EvaluationReason from the EvaluationDetail instance that can be retrieved.

Example:
Defined a number flag with two variations:
42.5 and 43.5

Whenever the , for example, the first variation is being returned, using 'intVariation', the returned value is 42.

Thanks,

Much appreciated.

[tanderson-ld]

Thank you for tell us about this usage. I have logged this internally as 1246 and will discuss with the team.

[tanderson-ld]

We discussed this today on team and we believe the alternatives of using doubleVariation to compare against or using 'jsonVariation' for more custom handling would meet the situation's needs. Had you considered those options? If so, was there an issue with them that we are missing?

[lirannesta]

We discussed this today on team and we believe the alternatives of using doubleVariation to compare against or using 'jsonVariation' for more custom handling would meet the situation's needs. Had you considered those options? If so, was there an issue with them that we are missing?

Thanks for the followup.

The business flow is as follows:
A P.O defines a flag as double in the LD platform.
The dev team is in charge of implementing a feature while using this flag.
Dev team has made a mistake and implemented intVariation instead of doubleVariation for evaluating the flag, thus the code is vulnerable to bugs.

Myself, as a developer who wraps the LD Java SDK for the mentioned Dev team above, would like to have the situation detected (rounding occurrence) and, at least, logged for warning.

We would like to keep the process as strict as possible , meaning, keep having the P.O define the most accurate type when he's defining the flag, and not having him defining json type at all, thus, leaving nothing open for interpretation.

I hope this further elaborates the use case and flow, and as a result, the technical enhancement request.