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.go → triggerWorkflowRun():
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:
- 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
- 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.
Summary
When trialing multiple workflows together with an issue
--trigger-context,gh aw trialforwardsissue_numberto every workflow — including scheduled/global workflows whoseworkflow_dispatchschema does not declare that input. The dispatch fails with HTTP 422 and the workflow is silently never run.Environment
main(v0.85.1)Reproduction
Trial an issue-triggered workflow and a scheduled/global workflow together, passing an issue trigger context:
Actual
The scheduled workflow installed successfully but was never dispatched.
Code pointer (on
main)pkg/cli/trial_helpers.go→triggerWorkflowRun():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
ghHTTP 422, with no explanation that the input was injected by the trial itself and no guidance on how to proceed.Suggested behavior
Either:
workflow_dispatchschema declares them (the lock file is already available locally at dispatch time), or--trigger-context.Option 1 is preferable, since mixed trials of an entity-triggered workflow plus a scheduled companion workflow are a natural use case.