override_data / override_resource: `values` naming a non-computed argument is rejected (Terraform accepts it)
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
OpenTofu v1.12.6
OpenTofu v1.13.0-beta1Both affected. Terraform 1.8.3 and 1.16.2 accept the same configuration.
OpenTofu Configuration Files
main.tf:
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:
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 overriddenExpected 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
tofu inittofu 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_dataproblems, 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:
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.
Source: opentofu/opentofu