Skip to content

trial: forwards issue_number to workflows that don't declare it, causing HTTP 422 and a silently skipped dispatch #50584

Description

@loganrosen

Summary

When trialing multiple workflows together with an issue --trigger-context, gh aw trial forwards issue_number to every workflow — including scheduled/global workflows whose workflow_dispatch schema does not declare that input. The dispatch fails with HTTP 422 and the workflow is silently never run.

Environment

  • gh-aw: observed on v0.84.3; code path still present on main (v0.85.1)
  • OS: macOS

Reproduction

Trial an issue-triggered workflow and a scheduled/global workflow together, passing an issue trigger context:

gh aw trial ./issue-workflow.md ./scheduled-workflow.md \
  --host-repo owner/host \
  --logical-repo owner/target \
  --trigger-context https://github.com/owner/target/issues/123 \
  --yes

Actual

HTTP 422: Unexpected inputs provided: ["issue_number"]

The scheduled workflow installed successfully but was never dispatched.

Code pointer (on main)

pkg/cli/trial_helpers.gotriggerWorkflowRun():

if triggerContext != "" {
    issueNumber := parseIssueSpec(triggerContext)
    if issueNumber != "" {
        args = append(args, "--field", "issue_number="+issueNumber)
    }
}

The input is appended unconditionally for every workflow in the trial, with no check against the compiled lock file's declared workflow_dispatch.inputs.

Impact

In a mixed-trigger trial, part of the trial silently does not execute. The failure surfaces only as a raw gh HTTP 422, with no explanation that the input was injected by the trial itself and no guidance on how to proceed.

Suggested behavior

Either:

  1. Forward trigger-derived inputs only to workflows whose compiled workflow_dispatch schema declares them (the lock file is already available locally at dispatch time), or
  2. Reject mixed trigger types before installation with a clear explanation of which workflows cannot accept the given --trigger-context.

Option 1 is preferable, since mixed trials of an entity-triggered workflow plus a scheduled companion workflow are a natural use case.

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions