Skip to content
Latchkey

GitHub Actions Reusable Workflow Input Type Mismatch

A reusable workflow declares an input as boolean or number, but the caller passes a quoted string (or a string expression), and the strict workflow_call typing rejects or mis-evaluates it.

What this error means

The caller fails validation with a type error, or the called workflow treats a boolean input as an always-truthy string, so an if: inputs.flag check behaves incorrectly.

.github/workflows/release.yml
# called workflow declares: enabled: { type: boolean }
# caller passes a string, which is not a boolean
with:
  enabled: 'true'   # rejected or treated as a string, not a real boolean

Common causes

String passed to a typed input

workflow_call inputs are strictly typed as string, boolean, or number. Passing a quoted string to a boolean input does not coerce cleanly and an if check on it can be wrong.

Expression result is a string

Any ${{ }} expression yields a string. Feeding it to a boolean or number input requires the called workflow to interpret it, or a fromJSON to coerce.

How to fix it

Pass the correct literal type

.github/workflows/release.yml
# caller
with:
  enabled: true        # real boolean literal
  retries: 3           # real number literal

Coerce expression results explicitly

When a value comes from an expression, convert it to the declared type with fromJSON.

.github/workflows/release.yml
with:
  enabled: ${{ fromJSON(steps.flags.outputs.enabled) }}   # "true" -> boolean true

How to prevent it

  • Declare each workflow_call input with the type it truly is.
  • Pass boolean and number literals unquoted from the caller.
  • Use fromJSON to coerce expression results to boolean or number.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →