Orquesta workflow: default value interpreted as string for parameter of number type

[m4dcoder]

I created an input parameter for the workflow of number type and provided a default value of 3. When the workflow is saved and I tried to execute it from the CLI, the command returns the following error.

ERROR: 400 Client Error: Bad Request
MESSAGE: '3' is not of type 'number' for url: http://127.0.0.1:9101/v1/executions

I reran the execution and provide the input parameter explicitly and the execution ran fine. So it looks like st2flow took the value 3 and interpreted it as a string value.

[bmomberger-bitovi]

This seems to be a problem with server side YAML parsing. Unquoted number-likes should be interpreted as numbers in YAML. If you make a JSON block out of the parameter it treats the 3 as a number, but that shouldn't be required to parse a number correctly.

[m4dcoder]

For this specific case, is it possible to post the action meta generated by st2flow here so I can take a look?

[bmomberger-bitovi]

Sure. here's a reduced case done through st2flow:

pack: default
name: my-orquesta-basic
runner_type: orquesta
entry_point: workflows/orquesta-basic.yaml
parameters:
  foo:
    type: number
    default: 3

[bmomberger-bitovi]

By "Make a JSON block out of a parameter" I mean that manually editing to this would not cause the same breakage:

pack: default
name: my-orquesta-basic
runner_type: orquesta
entry_point: workflows/orquesta-basic.yaml
parameters:
  foo: {
    "type": "number",
    "default": 3
  }

[m4dcoder]

Can you open an issue in st2 repo on this problem? In the issue, can you point out which API endpoint used? Thanks.

[bmomberger-bitovi]

While trying to replicate the problem I figured out I was wrong about the conditions.

It's not specifically a server issue:

• the params being sent to /api/v1/actions/ in the request body have strings for values if the details panel form was used to edit.
• The reducer isn't converting default values to the when the form sends its raw user-entered form value, and the form field component itself is not converting on known type before sending to the reducer. However, isn't this correct? The default can be a jinja expression that evaluates to an integer and that's accepted by execution, so we can't just assume that number forms are the only correct values
• Any update from editing the YAML will do a type conversion because the YAML parser (client side) will interpret the scalar values according to YAML rules (e.g. if it looks like a number, it is one).

So there's a who's-responsible issue at play. "Bad" data is passing through two or three gates client-side (neither components nor the reducer convert values) and one gate server side (saving doesn't reject when defaults don't match the type), and so then it falls on the execution engine to figure out that there is a type mismatch when loading the parameters from the database (not the file).

I will still file a bug in the API, but I see it as more of a violation of Postel's Law that you can't use a number in a string representation as a parameter value.

I will also put this issue into play to tighten up the controls on what's sent to the endpoint from st2flow, but let's make sure we have a complete agreement about how to handle things before addressing either this issue or the corresponding API one.

[m4dcoder]

You are correct in that the default value can be a Jinja expression and thus string type. So my initial take here is to let the server side try to handle the type conversion (i.e. if number and not an expression, try to convert it to number).