unable to find source vertex %q for dependency analysis, thi

Error message

unable to find source vertex %q for dependency analysis, this is likely a Packer bug

What it means

During buildPrereqsDAG, Packer builds a dependency graph of datasources and locals before evaluating build prerequisites. Each datasource block is supposed to have been added as a graph vertex in the first pass; if the vertex keyed by "data.<name>" is absent from verticesMap, this internal-consistency error is raised and the block is skipped. As the message says, this almost always indicates a Packer bug or corrupted in-memory config state rather than a template authoring mistake.

Source

Thrown at hcl2template/parser.go:441

		verticesMap[fmt.Sprintf("data.%s", ds.Name())] = v
	}
	// Note: locals being references to the objects already, we can safely
	// use the reference returned by the local loop.
	for _, local := range cfg.LocalBlocks {
		v := retGraph.Add(local)
		verticesMap[fmt.Sprintf("local.%s", local.LocalName)] = v
	}

	// Connect the vertices together
	//
	// Vertices that don't have dependencies will be connected to the
	// root vertex of the graph
	for _, ds := range cfg.Datasources {
		dsName := fmt.Sprintf("data.%s", ds.Name())

		source := verticesMap[dsName]
		if source == nil {
			err = multierror.Append(err, fmt.Errorf("unable to find source vertex %q for dependency analysis, this is likely a Packer bug", dsName))
			continue
		}

		for _, dep := range ds.Dependencies {
			target := verticesMap[dep.String()]
			if target == nil {
				err = multierror.Append(err, fmt.Errorf("could not get dependency %q for %q, %q missing in template", dep.String(), dsName, dep.String()))
				continue
			}

			retGraph.Connect(dag.BasicEdge(source, target))
		}
	}
	for _, loc := range cfg.LocalBlocks {
		locName := fmt.Sprintf("local.%s", loc.LocalName)

		source := verticesMap[locName]
		if source == nil {

View on GitHub (pinned to eb36e3c3e4)

Solutions

Upgrade Packer to the latest patch release — this is flagged as a bug; check the changelog for dependency-graph fixes
File a bug report (hashicorp/packer) including the template's datasource blocks and `packer version`
As a workaround, simplify/rename the datasource blocks (avoid duplicated or unusual names) and rebuild the cache to force fresh parsing
If embedding Packer programmatically, ensure cfg.Datasources is not mutated between config parsing and evaluateBuildPrereqs

Example fix

// No template fix applies; this is internal state.
// Workaround in a template: rename a possibly colliding datasource
// before
data "amazon-ami" "foo" { ... }
data "amazon-ami" "foo" { ... }  // duplicate name can corrupt vertex keys
// after
data "amazon-ami" "foo" { ... }
data "amazon-ami" "bar" { ... }

Defensive patterns

Strategy: validation

Validate before calling

// Before building, ensure every datasource parses and resolves:
//   packer validate template.pkr.hcl
// Programmatic check: iterate cfg.Datasources and confirm unique names
names := map[string]bool{}
for _, ds := range cfg.Datasources {
    n := fmt.Sprintf("data.%s", ds.Name())
    if names[n] { /* duplicate datasource name — vertex key collision risk */ }
    names[n] = true
}

Try / catch

if err != nil {
    // treat as internal bug: include `packer version`, template, and retry with a clean parse cache
    return fmt.Errorf("dependency analysis failed (possible Packer bug): %w", err)
}

Prevention

Keep Packer up to date; this error class is a bug indicator, not a config problem
Give datasource blocks unique names across all parsed files
Re-run from a clean state (no stale parse cache) after upgrading Packer
Validate templates with `packer validate` in CI to surface config issues before graph building

When it happens

Trigger: cfg.Datasources contains a datasource whose ds.Name() key was not registered in verticesMap during the first vertex pass (e.g. duplicate/odd datasource names colliding, or a block whose name changes between the first and second passes). Called via evaluateBuildPrereqs when Packer starts evaluating build prerequisites (packer build / validate of an HCL2 template with datasource blocks).

Common situations: Packer core regressions after upgrades, plugin SDK versions where datasource Name() behaves unexpectedly, custom forks or embedded use of PackerConfig where cfg.Datasources is mutated between passes. Rarely triggered by pure template content.

Related errors

AI-assisted analysis of hashicorp/packer@eb36e3c3e4 (2026-09-05). Data as JSON: /api/errors/8573dbeeaa86c84a. Report an issue: GitHub.