What causes "failed to read dependency lock file: %s" in hashicorp/terraform?

Inspect .terraform.lock.hcl for syntax errors or unresolved merge conflict markers ( >>>>>>).

failed to read dependency lock file: %s

Error message

failed to read dependency lock file: %s

What it means

Raised when ProviderFactories cannot read/parse the dependency lock file (.terraform.lock.hcl). lockedDependencies() returned diagnostics with errors — the lock file is missing required fields, corrupt, or unreadable. The lock file pins provider versions and checksums; without a valid one Terraform cannot resolve provider factories.

Source

Thrown at internal/command/meta_providers.go:314

		),
	}
}

// ProviderFactories uses the selections made previously by an installer in
// the local cache directory (m.providerLocalCacheDir) to produce a map
// of provider addresses to factory functions to create instances of
// those providers.
//
// ProviderFactories will return an error if the installer's selections cannot
// be honored with what is currently in the cache, such as if a selected
// package has been removed from the cache or if the contents of a selected
// package have been modified outside of the installer. If it returns an error,
// the returned map may be incomplete or invalid, but will be as complete
// as possible given the cause of the error.
func (m *Meta) ProviderFactories() (map[addrs.Provider]providers.Factory, error) {
	locks, diags := m.lockedDependencies()
	if diags.HasErrors() {
		return nil, fmt.Errorf("failed to read dependency lock file: %s", diags.Err())
	}

	return m.providerFactoriesFromLocks(locks)
}

// ProviderFactoriesFromLocks receives in memory locks and uses them to produce a map
// of provider addresses to factory functions to create instances of
// those providers.
//
// ProviderFactoriesFromLocks should only be used if the calling code relies on locks
// that have not yet been persisted to a dependency lock file on disk. Realistically, this
// means only code in the init command should use this method.
func (m *Meta) ProviderFactoriesFromLocks(configLocks *depsfile.Locks) (map[addrs.Provider]providers.Factory, error) {
	// Ensure overrides and unmanaged providers are reflected in the returned list of factories,
	// while avoiding mutating the in-memory
	locks := m.annotateDependencyLocksWithOverrides(configLocks.DeepCopy())

	return m.providerFactoriesFromLocks(locks)

View on GitHub (pinned to c9def3e214)

Solutions

Inspect .terraform.lock.hcl for syntax errors or unresolved merge conflict markers (<<<<<<<, =======, >>>>>>>).
Resolve conflicts and run `terraform init` to regenerate the lock file.
If the file is unrecoverable, back it up and delete it, then `terraform init -upgrade` to recreate it.
Ensure the Terraform version is compatible with the lock file format.

Example fix

// before
// .terraform.lock.hcl has unresolved git merge conflict -> error

// after
# resolve conflict markers, then:
terraform init
# or regenerate from scratch:
cp .terraform.lock.hcl .terraform.lock.hcl.bak && rm .terraform.lock.hcl && terraform init -upgrade

Defensive patterns

Strategy: validation

Validate before calling

// Lint the lock file for unresolved conflicts before running plan/apply
func lockFileClean(path string) bool {
    b, _ := os.ReadFile(path)
    s := string(b)
    return !strings.Contains(s, "<<<<<<<") && !strings.Contains(s, "=======" ) && !strings.Contains(s, ">>>>>>>")
}
if !lockFileClean(".terraform.lock.hcl") {
    return fmt.Errorf("resolve merge conflicts in lock file first")
}

Prevention

Resolve git merge conflicts in .terraform.lock.hcl before running terraform.
Never hand-edit the lock file; regenerate via `terraform init`.
Keep Terraform versions consistent across the team to avoid lock schema drift.
Back up and regenerate a corrupt lock file with terraform init -upgrade.

When it happens

Trigger: ProviderFactories: m.lockedDependencies() returns diags.HasErrors()==true. Triggered by a hand-edited/malformed .terraform.lock.hcl, a lock file from an incompatible Terraform version, partial merge conflicts left in the lock file, or a permissions/IO error reading it.

Common situations: Git merge conflict in .terraform.lock.hcl left unresolved; lock file partially deleted; lock file written by a newer Terraform with schema the current version rejects; lock file manually edited and broken.

Related errors

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