Skip to content

dispatch-workflow validation is compile-order dependent and can require a second pass for same-batch targets #20031

@samuelkahessay

Description

@samuelkahessay

Context

Observed while compiling a workflow set where one agentic workflow dispatches another (prd-decomposer -> repo-assist) during the March 8, 2026 autonomy hardening pass. The first gh aw compile pass failed, the second pass succeeded with no source changes.

Still reproducible on local gh-aw main at b2d8af754 (v0.53.4).

Problem

validateDispatchWorkflow() validates referenced workflows against files already present on disk. If the referenced workflow exists only as .md and is being compiled in the same batch, validation still fails with "must be compiled first".

This makes same-batch dispatcher dependencies compile-order dependent and can force a second pass when the dispatcher is processed before its target.

Location

  • pkg/workflow/dispatch_workflow_validation.go:61-108
  • pkg/workflow/safe_outputs_config_generation.go:121-137

Reproduction

  1. Create b.md with a valid workflow_dispatch trigger
  2. Create a.md with:
safe-outputs:
  dispatch-workflow:
    workflows:
      - b
  1. Ensure b.lock.yml does not already exist
  2. Run gh aw compile in a directory where a.md is discovered before b.md

Expected: both workflows compile in one pass

Actual: a.md fails validation because b.lock.yml is missing, even though b.md is part of the same compile batch

Expected behavior

The compiler should resolve same-batch workflow dependencies and accept referenced markdown workflows that are about to emit .lock.yml in the current compile invocation.

Proposed fix

Two possible approaches:

Option A — batch-aware validation: Pass the compile set into validateDispatchWorkflow() so it can recognize same-batch .md targets as valid:

  • build a map of markdown workflows that will emit .lock.yml
  • use that map in validation and workflow_files population
  • only require a pre-existing lock file for workflows that are not part of the current batch

Option B — topological compile ordering: Sort workflows by dispatch dependencies before compiling, so referenced targets are always emitted before their dispatchers:

  • build a dependency graph from dispatch-workflow.workflows references
  • compile in topological order (targets before dispatchers)
  • simpler than making validation batch-aware, but requires cycle detection

Environment

  • Observed in production bootstrap tooling: v0.52.1 workflow set
  • Still present on: local main at b2d8af754 (v0.53.4)

Metadata

Metadata

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions