#4568·opentofu

override_data / override_resource: `values` naming a non-computed argument is rejected (Terraform accepts it)

Author: tun0Created Sep 9, 2026Updated Sep 10, 2026
Labelsenhancementpending-decision

Community note

[!TIP] Hi there, OpenTofu community! The OpenTofu team prioritizes issues based on upvotes. Please make sure to upvote this issue and describe how it affects you in detail in the comments to show your support.

OpenTofu Version

bash
OpenTofu v1.12.6
OpenTofu v1.13.0-beta1

Both affected. Terraform 1.8.3 and 1.16.2 accept the same configuration.

OpenTofu Configuration Files

main.tf:

hcl
terraform {
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "2.5.2"
    }
  }
}

data "local_file" "example" {
  filename = "does-not-exist.txt"
}

output "content" {
  value = data.local_file.example.content
}

main.tftest.hcl:

hcl
override_data {
  target = data.local_file.example
  values = {
    filename = "overridden.txt"
    content  = "overridden content"
  }
}

run "check" {
  command = plan

  assert {
    condition     = output.content == "overridden content"
    error_message = "expected the overridden content"
  }
}

Debug Output

Error: Invalid mock/override field `filename`

Error: Non-computed field `filename` is not allowed to be overridden

Expected Behavior

The override_data block replaces the data source entirely, so supplying a value for an argument alongside the computed attributes is accepted and the run passes. Terraform reports Success! 1 passed, 0 failed. on both 1.8.3 and 1.16.2.

Actual Behavior

OpenTofu rejects the block because filename is an argument rather than a computed attribute, and the whole test file fails.

Steps to Reproduce

  1. tofu init
  2. tofu test

Additional Context

I am not sure whether this is a bug or a deliberate design choice — refusing to override something the configuration already controls is defensible. Raising it because it is a behavioural difference from Terraform that breaks otherwise-portable test files, and because the diagnostic reads as a hard error rather than a documented restriction.

Our real case is a data source whose name argument is echoed back by the provider, so the override lists it next to id to describe the object as a whole. Dropping the argument from values is a viable workaround if the current behaviour is intended — in which case documenting the restriction (and ideally naming the offending field as a warning rather than failing the file) would be enough.

override_data type-checking was tightened in #1903 / #2220 (warning to error on type mismatch); this is a different rule — field kind rather than value type. I could not find an existing issue for it.

References

  • #2008 — earlier override_data problems, closed
  • #1903 / #2220 — warning-to-error change for incorrect override value types

Workaround

Omit the argument from values and let it resolve from the configuration as normal:

hcl
override_data {
  target = data.local_file.example
  values = {
    content = "overridden content"
  }
}

Verified on OpenTofu 1.12.6 and 1.13.0-beta1, and still passing on Terraform 1.8.3 and 1.16.2. data.local_file.example.filename still evaluates to the value in the configuration, so nothing is lost as long as the argument is one the test already controls. That is a good sign the current restriction is at least defensible — but the diagnostic gives no hint that dropping the field is the intended shape.