registry response to request for %s archive has incorrect ta

Error message

registry response to request for %s archive has incorrect target %s

What it means

PackageMeta requested an archive for a specific Platform (target.OS/target.Arch) but the registry's response body reported a different OS/Arch. This sanity check prevents silently installing a binary built for the wrong platform, so the mismatch is rejected with a plain fmt.Errorf.

Source

Thrown at internal/getproviders/registry_client.go:280

		for _, version := range protoVersions {
			if supportedProtos.Has(version) {
				match = true
			}
		}
		if !match {
			// If the protocol version is not supported, try to find the closest
			// matching version.
			closest, err := c.findClosestProtocolCompatibleVersion(ctx, provider, version)
			if err != nil {
				return PackageMeta{}, err
			}
			protoErr.Suggestion = closest
			return PackageMeta{}, protoErr
		}
	}

	if body.OS != target.OS || body.Arch != target.Arch {
		return PackageMeta{}, fmt.Errorf("registry response to request for %s archive has incorrect target %s", target, Platform{body.OS, body.Arch})
	}

	downloadURL, err := url.Parse(body.DownloadURL)
	if err != nil {
		return PackageMeta{}, fmt.Errorf("registry response includes invalid download URL: %s", err)
	}
	downloadURL = resp.Request.URL.ResolveReference(downloadURL)
	if downloadURL.Scheme != "http" && downloadURL.Scheme != "https" {
		return PackageMeta{}, fmt.Errorf("registry response includes invalid download URL: must use http or https scheme")
	}

	ret := PackageMeta{
		Provider:         provider,
		Version:          version,
		ProtocolVersions: protoVersions,
		TargetPlatform: Platform{
			OS:   body.OS,
			Arch: body.Arch,

View on GitHub (pinned to c9def3e214)

Solutions

Verify the requested platform string (GOOS/GOARCH) is one the registry actually serves.
Check the registry backend routes the OS/Arch path segments correctly to the matching archive.
Clear any CDN/mirror cache keyed without the platform dimension.
Confirm the registry returns os/arch in the exact vocabulary Terraform sends (e.g. "amd64" not "x86_64").

Example fix

// before: request linux/amd64, registry returns
{"os":"darwin","arch":"arm64",...}
// after: registry returns the requested target
{"os":"linux","arch":"amd64",...}

Defensive patterns

Strategy: validation

Validate before calling

// Before calling PackageMeta, confirm the platform is one the registry serves
// by listing versions+platforms and matching OS/Arch exactly.
func platformServed(available map[string][]Platform, ver string, want Platform) bool {
    for _, p := range available[ver] {
        if p.OS == want.OS && p.Arch == want.Arch {
            return true
        }
    }
    return false
}

Try / catch

meta, err := client.PackageMeta(ctx, provider, ver, plat)
if err != nil {
    if strings.Contains(err.Error(), "incorrect target") {
        // registry served a different platform; surface a clearer message to the user
    }
    return err
}

Prevention

Request a platform the registry actually publishes (check the versions/platforms list first).
For custom registries, ensure the download endpoint honors the OS/Arch path segments.
Keep the registry's platform vocabulary aligned with Terraform's (GOOS/GOARCH).

When it happens

Trigger: Registry download endpoint echoes back OS/Arch that do not match the path the installer requested (e.g. asked for linux/amd64, got darwin/arm64). Typically a registry routing bug, a mirror returning a cached package for the wrong target, or a hand-built registry ignoring the platform path segment.

Common situations: Custom registry ignores platform path and always returns amd64; CDN cache key omits platform; registry upgraded its API and the os/arch field names drifted; requesting an arch the registry maps differently (e.g. "x86_64" vs "amd64").

Related errors

AI-assisted analysis of hashicorp/terraform@c9def3e214 (2026-08-07). Data as JSON: /api/errors/3510dfdef2b03b34. Report an issue: GitHub.