Syntax error when input of type 'number' are forwarded by 'workflow_dispatch' to the reused workflow

[kunalherkal]

Select Topic Area

Bug

Body

Describe the bug
When a 'workflow_dispatch' calls reusable workflow, and forwards it's input of type 'number' to the called workflow, it results into syntax error.

To Reproduce
This is the reusable workflow that is called:

name: Called workflow

on:
  workflow_call:
    inputs:
      inputA:
        description: Number input
        required: true
        type: number
      inputB:
        description: String input
        required: true
        type: string

jobs:
  print_hello_world:
    runs-on: ubuntu-latest
    steps:
      - name: Print inputs
        run: echo "Hello world"

This is the caller workflow that calls above workflow:

name: Caller Workflow

on:
  workflow_dispatch:
    inputs:
      inputA:
        description: Number input
        required: true
        type: number
      inputB:
        description: String input
        required: true
        type: string

jobs:
  call_reusable_workflow:
    uses: ./.github/workflows/called-workflow.yml
    with:
      inputA: ${{ inputs.inputA }}
      inputB: ${{ inputs.inputB }}

Error:
When triggering the workflow_dispatch using UI, I pass 1000 as value for inputA and some string for inputB.
The job doesn't even start and I see following syntax error:

Caller Dispatch Workflow: .github#L1
The template is not valid. .github/workflows/caller-workflow.yml (Line: 19, Col: 15): Unexpected value '1000'

Also if I hardcode inputA when calling the called workflow, run succeeds. for example:

jobs:
  call_reusable_workflow:
    uses: ./.github/workflows/called-workflow.yml
    with:
      inputA: 1000
      inputB: ${{ inputs.inputB }}

Expected behavior
There should be no syntax error in the case explained above.

Runner Version and Platform

Version of your runner?
Github Hosted: '2.309.0'

OS of the machine running the runner? OSX/Windows/Linux/...

Ubuntu
  22.04.3
  LTS

[danikv]

Also having this problem, any suggestions ?

[unru006]

Just experienced that bug as well - still no reaction on this? :-(

[sszemeresky]

same issue here, guys this is crucial :|

[CrimsonEdgeHope]

Exact issue in my repo's workflow.
Perhaps a workaround can be setting the type to string, leave conversion to inside the workflow.😕

[sherbie]

This is the workaround I use with an additional type assertion in a shell script.

[sszemeresky]

This is the workaround I use with an additional type assertion in a shell script.

could you please share your solution? I'm wanting to use an input as a nr of matrix elements to run tests on x workers

[PrzemekZglinicki]

Same problem here - https://github.com/OxlaCom/Oxla/actions/runs/7543017434

[arjan-noordende]

Same here. This is clearly a bug that needs picking up.

[legoGoat]

I ran into this yesterday as well. I tried all sorts, even found the old GHA bug where one couldn't pass caller workflow's inputs. variables into a called workflow's with block, which has long since been resolved.
But, yes, it seems like at some point between being input into the first workflow and trying to pass into the second workflow, a number stops being a number and it is just passed around as a string.
So, on.workflow_call.inputs.variable-name.type: number is clearly a big no, doesn't work. ❌ 😬

[paupujolasparset]

As a workarround I use the fromJson expression.

In the example above would be:

call_reusable_workflow:
    uses: ./.github/workflows/called-workflow.yml
    with:
      inputA: ${{ fromJson(inputs.inputA) }}
      inputB: ${{ inputs.inputB }}

[TWiStErRob]

fromJSON

[KevinMind]

Same issue here mozilla/addons#14904

[Krikooo]

Same issue on my side :c

[sherbie]

Same problem. Dysfunctional input validation should be a higher priority to fix.

[iamludal]

Same problem here. Using fromJson as a workaround.

[jay-lu-simplisafe]

still a problem as of today