hashicorp/packer · error

failed to get build %q from version being built. This is a P

Error message

failed to get build %q from version being built. This is a Packer bug.

What it means

After uploading artifacts, doCompleteBuild looks up the build in the locally tracked Version via bucket.Version.Build(buildName) to finalize it. If the lookup fails, the build was never stored in the version's build map during populateVersion/startBuild — an internal invariant violation, so Packer labels it a Packer bug rather than a user error.

Source

Thrown at internal/hcp/registry/types.bucket.go:798

			log.Printf("[WARN] - artifact %q returned a nil value for the HCP state, ignoring", art.BuilderId())
			continue
		}

		err = decoder.Decode(state)
		if err != nil {
			log.Printf("[WARN] - artifact %q failed to be decoded to an HCP artifact, this is probably because it is not compatible: %s", art.BuilderId(), err)
			continue
		}

		err = bucket.UpdateArtifactForBuild(buildName, sdkImages...)
		if err != nil {
			return packerSDKArtifacts, fmt.Errorf("failed to add artifact for %q: %s", buildName, err)
		}
	}

	build, err := bucket.Version.Build(buildName)
	if err != nil {
		return packerSDKArtifacts, fmt.Errorf(
			"failed to get build %q from version being built. This is a Packer bug.",
			buildName)
	}
	if len(build.Artifacts) == 0 {
		return packerSDKArtifacts, &NotAHCPArtifactError{
			fmt.Errorf("No HCP Packer-compatible artifacts were found for the build"),
		}
	}

	for _, sbom := range build.CompressedSboms {
		err = bucket.uploadSbom(ctx, buildName, sbom)
		if err != nil {
			return packerSDKArtifacts, fmt.Errorf("Failed to upload sboms %s", err)
		}
	}

	parErr := bucket.markBuildComplete(ctx, buildName)
	if parErr != nil {

View on GitHub (pinned to eb36e3c3e4)

Solutions

  1. Report to hashicorp/packer with full log output — the message explicitly indicates a Packer bug
  2. Ensure the normal flow is used: Initialize -> StartBuild -> CompleteBuild with the same bucket instance and build name
  3. Verify the build's component type in the template matches what was registered in HCP Packer
  4. If driving the API programmatically, call populateVersion/StoreBuild for the build before completing it
Defensive patterns

Strategy: try-catch

Validate before calling

// Only call CompleteBuild for builds that went through Initialize/StartBuild
// if !bucket.IsExpectingBuildForComponent(buildName) {
//     return fmt.Errorf("build %q was never registered; call Initialize first", buildName)
// }

Type guard

// Go: verify the build exists in the tracked version before completing
if _, err := bucket.Version.Build(buildName); err != nil {
	return fmt.Errorf("build %q not tracked; initialize the bucket first", buildName)
}

Try / catch

// Go
_, err := bucket.CompleteBuild(ctx, buildName, arts, ui, nil)
if err != nil && strings.Contains(err.Error(), "This is a Packer bug") {
	// internal invariant broken: report upstream with full logs
	return fmt.Errorf("packer internal error, please report: %w", err)
}

Prevention

When it happens

Trigger: Bucket.CompleteBuild -> doCompleteBuild reaches bucket.Version.Build(buildName) and receives an error, meaning the build name was never registered via StoreBuild during Initialize/PopulateVersion or was registered under a different component type.

Common situations: Custom tooling or tests driving the registry Bucket API out of order (calling CompleteBuild without Initialize/StartBuild); component-type name mismatches between the template and the registry; genuine Packer bugs in build tracking.

Related errors


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