provider %s: version constraints %q don't match the locked v

Error message

provider %s: version constraints %q don't match the locked version selection %s

What it means

Same check as 804 but the constraint strings match (the `default` branch at line 314): the locked selected version is simply not in allowedVersions for those unchanged constraints. Usually means the lock recorded a version that no longer satisfies: a hand-edited lock, a provider yanking an old release so the resolver's set shrank, or constraints tightened in a way init didn't propagate.

Source

Thrown at internal/configs/config.go:314

		selectedVersion := lock.Version()
		allowedVersions := providerreqs.MeetingConstraints(constraints)
		log.Printf("[TRACE] Config.VerifyDependencySelections: provider %s has %s to satisfy %q", providerAddr, selectedVersion.String(), providerreqs.VersionConstraintsString(constraints))
		if !allowedVersions.Has(selectedVersion) {
			// The most likely cause of this is that the author of a module
			// has changed its constraints, but this could also happen in
			// some other unusual situations, such as the user directly
			// editing the lock file to record something invalid. We'll
			// distinguish those cases here in order to avoid the more
			// specific error message potentially being a red herring in
			// the edge-cases.
			currentConstraints := providerreqs.VersionConstraintsString(constraints)
			lockedConstraints := providerreqs.VersionConstraintsString(lock.VersionConstraints())
			switch {
			case currentConstraints != lockedConstraints:
				errs = append(errs, fmt.Errorf("provider %s: locked version selection %s doesn't match the updated version constraints %q", providerAddr, selectedVersion.String(), currentConstraints))
			default:
				errs = append(errs, fmt.Errorf("provider %s: version constraints %q don't match the locked version selection %s", providerAddr, currentConstraints, selectedVersion.String()))
			}
		}
	}

	// Return multiple errors in an arbitrary-but-deterministic order.
	sort.Slice(errs, func(i, j int) bool {
		return errs[i].Error() < errs[j].Error()
	})

	return errs
}

// ProviderRequirements searches the full tree of modules under the receiver
// for both explicit and implicit dependencies on providers.
//
// The result is a full manifest of all of the providers that must be available
// in order to work with the receiving configuration.
//

View on GitHub (pinned to c9def3e214)

Solutions

Run `terraform init -upgrade` to recompute the selected version under the existing constraints.
If you intentionally pin a specific version, make the constraint match (e.g. `= 1.2.0`) rather than editing the lock directly.
Inspect the lock file, remove the corrupted provider block, then `terraform init` to regenerate it.

Example fix

// before: constraint ">= 1.3.0", lock selected "1.2.0"

$ terraform init -upgrade
// after: lock selected "1.3.x" satisfying the constraint

Defensive patterns

Strategy: validation

Validate before calling

// Never edit .terraform.lock.hcl by hand; regenerate via `terraform init` /
// `terraform providers lock -platform=...`. In Go, assert lock.Version() is in
// providerreqs.MeetingConstraints(configConstraints) before plan.

Prevention

Regenerate locks only through terraform init / terraform providers lock.
Pin exact versions with `=` constraints when reproducibility matters.
Run terraform init -upgrade after provider withdrawals to refresh the selectable set.

When it happens

Trigger: Manually editing the lock file's version field, a constraint like `>= 1.3.0` paired with a lock still on 1.2.0 after a partial/failed init, or a provider release being withdrawn so the version is no longer selectable.

Common situations: Hand-editing .terraform.lock.hcl, partial init across providers, constraint and lock updated out of order.

Related errors

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