refactor(api): be more permissive with accepting int literals for float parameters #14820
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
In the course of integrating runtime parameters frontend and backend work, it was discovered that for floating point parameters with a minimum and maximum range, if a literal int or value with only
.0
was entered, the parameter validation would fail as the typeint
did not match the acceptedfloat
.While discussing this, it was determined that it would be best to allow those values, while also being less strict in the parameter definition creation
ParameterContext.add_float
. This permissiveness does not go the other way for parameter definitions, if a user adds something like6.0
as a default forParameterContext.add_int
, that will still raise an error (value sent over to one of the endpoints however will do this conversion, due to how we defined our Pydantic types). Other values sent over will also not be converted but instead raise the appropriate error elsewhere. This includes values likebool
which can be type converted in Python, a value of True will also not be converted to 1.Test Plan
Verified via postman that sending an int literal value for a float parameter override accepts the value and does not error out. Also ensure that this protocol passed analysis.
Changelog
default
,minimum
,maximum
and value key ofchoices
forParameterContext.add_float
Review requests
Risk assessment
Low.