You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unknown parameter default coerced to null skips the 'value is unknown' diagnostic #225
A parameter whose default is an unknown value can surface either as an error diagnostic or as a silent null, depending on how the unknown arrives. Both cases are "the value could not be resolved", but only one of them tells the user.
resource"docker_image""base" { name="large" }
data"coder_parameter""computed" {
name="computed"type="string"default=docker_image.base.image_id# computed attribute, unknown at plan time
}
DefaultValue is cty.DynamicVal, Value ends up as a typed null, and the parameter carries no diagnostics.
Compare a default that is unknown because a reference has no value (for example default = local.x where local.x reads a block that does not exist). There the value stays an unknown and ParameterUsageDiagnostics emits:
Parameter value is unknown, it likely includes a reference without a value
Where it diverges
extract/parameter.go, ParameterUsageDiagnostics:
ifp.Value.Value.IsNull() {
// Allow null values
} elseif!p.Value.Valid() {
...
} elseif!p.Value.IsKnown() {
..."Parameter value is unknown" ...
}
The null branch is checked first, so an unknown default that is coerced to a typed null on the way to Value skips both the "not valid" and "unknown" branches, even though Valid() and IsKnown() are both false on it.
Expected
Either both shapes report the same "unknown / unresolved" diagnostic, or neither does. A user writing default = <computed attribute> gets a required-but-empty parameter in the form with no explanation today.
Activity