Request validation fails for arguments expecting a Float when the input has no decimal part

[gregopet]

Version

5.0.1

Context

I expected the validation of a float parameter to pass if the input had no decimal part, instead it fails with number does not match the format

Steps to reproduce

• declare a property of type float: { "type": "number", "format": "float" }
• send a request where the value of this property is e.g. 10
• validation fails with number does not match the format

Do you have a reproducer?

No response

[gregopet]

I have opened a pull request where I added the test case for this issue to the existing test cases.

[thced]

This is an issue in 4.5.22 as well.

[tsegismont]

@pk-work any chance for you to look into this one?

[pk-work]

Hi,
so there are two ways to fix this.

Solution 1:
We can relax the checks in OpenAPIFormatValidator and also allow Long or Integer. But then we need to check that these values are smaller than 2^24 (float) and 2^53 (double).

Solution 2:
We can check here if the schema type is number and add a .0 at the end, if it does not already contain a ..
But then we have the issue that Jackson simply transforms the value in a double .. so we don't have a warning if the value was bigger than 2^53. Therefore I would prefer solution 1.

But in my opinion this is not the real problem.

The problem is, that you specify a specific format in the contract and then send data which does not fit to this format ... So if you don't care about the format, why have you specified one? Just say it is a number and you are fine.

What do you think?

[pk-work]

If we would implement Solution 1, we would have a different behavior in case you would send

9223372036854775807 -> would be rejected
9223372036854775807.0 -> would be transformed into Double and information gets lost.

So maybe we should implement solution 2, to have the same behavior. And if this really becomes an issue we would need to fix it in general also for the case where jackson is involved.

[thced]

For context, our issue is that the format is set as double, and the number is a percentage, or a monetary amount; so sometimes it becomes 25.0, which translates to 25 of course (which is still a valid double) but then fails with the mentioned error.

[pk-work]

Okay, but if 25 is a valid representation for this value, why do you specify the format "double"? So in which cases do you have an advantage? You could simply remove the format and have the expected behavior.

[tsegismont]

What does the spec say about numeric format?

[pk-work]

The spec doesn't say something about the representation. It defines the precision [1].

At the moment we don't implement this check [2] correctly. So the only thing we are checking is, if it is a Double, Float and NaN. I think when @CheesyBoy123 implemented this feature the main aspect was int32 and int64.

If it is a Double or not depends on Jackson. If there is no . in the number, Jackson will it always transform to an integer.

So that is the real problem. For now, you should simply remove the format and you are fine. For the future we should have a correctly implemented check on the format, which focus on the precision and also allows numbers without a ..

Any volunteer for the implementation of the format check? I can assist.

[1] https://spec.openapis.org/registry/format/double
[2]

vertx-openapi/src/main/java/io/vertx/openapi/impl/OpenAPIFormatValidator.java

Lines 17 to 33 in c4a4525

	if ("float".equalsIgnoreCase(format)) {
	// Behind the scenes we use jackson, so even floats are converted into doubles for us.
	// So now we will down cast the float back into a double, and check the usual isInfinite and isNan.
	if (!(instance instanceof Double) || ((Float) ((Double) instance).floatValue()).isInfinite()
	|| ((Float) ((Double) instance).floatValue()).isNaN()) {
	return getMessage(format);
	}
	}
	if ("float".equalsIgnoreCase(format) || "double".equalsIgnoreCase(format)) {
	if (!(instance instanceof Double) || ((Double) instance).isInfinite() || ((Double) instance).isNaN()) {
	return getMessage(format);
	}
	}
	return null;
	}

[thced]

Maybe I misread something when I stated it is considered a valid double even though there is no dot present; from our applications perspective, we would want to always expect a double, with a dot.