I’m seeing an issue in one of our internal repositories. Unfortunately I’m unable to reproduce a smaller version.
I have a data source that is used like this:
data "custom_data_source" "current" {}
module "foo" {
name = "foo-${data.custom_data_source.current.environment}"
}
This generally works well, the provider is configured correctly and returns the correct result. I’ve tried to recreate the error with a small example but it just seems to work. However when we’re in our main codebase we’re getting the error similar to below, that the value is null:
44: "foo-${data.custom_data_source.current.environment}",
│ ├────────────────
│ │ data.custom_data_source.current is null
│
│ The expression result is null. Cannot include a null value in a string
│ template.
We previously saw this error and managed to fix it through trial and error by removing depends_on=... statements. We think it had something to do with dependencies, but didn’t get to the bottom of it. I’ve read here that the data source evaluation can be delayed to apply time under certain conditions and I think (not sure) that’s what is going on here, but don’t fully understand exactly when this occurs or why this could occur. The data source is empty and relies entirely on provider configuration so don’t understand why this would ever happen as it never depends on another resource.
Has anyone seen anything similar or can provide more information on what causes data source evaluation to be delayed (and what the output looks like in terraform).
Hi @sapenroo,
A data source’s evaluation can be deferred to apply if it depends on any other changes in the configuration, either because the data source’s configuration is not entirely known, or because of explicit dependencies like depends_on.
That however is not what is happening here, both because you are not seeing unknown values, but the entire data source itself is being reported as null. I’m not sure how you arrived at that error, because a data source cannot return a null value, and the object type of the data source cannot be used in a string template and would produce a different error about an “object with N attributes”.
I have a feeling this is all caused by an incorrect data source implementation. If there are no computed attributes in the data source schema, there is no additional output that the data source could provide, so the empty configuration value would be all Terraform can see.
1 Like
Thank your for your response. I now know it’s not being delayed.
I managed to recreate the bug with depends_on in a test repo. I decided to swap out the data source with another, and the run succeeded so it does indeed look like a but in the provider implementation.
I’ve tried to running the provider externally in a debugger it and it looks like without depends_on the various internal functions are called. With depends_on the internal provider functions aren’t called at all - at least the same break points aren’t hit, which would explain why we’re getting a null value (still not sure why). Need to do some more debugging here but you put me on the right track - thanks!
After some debugging I can see that terraform isn’t sending the grpc request tfplugin5.Provider/ReadDataSource when depends_on is present. We get to the same point where we receive a Configure request after which terraform crashes. In the successful case we receive two more calls, ValidateDataSourceConfig and then ReadDataSource. I’m unsure why terraform it not continuing - I don’t have enough context on the provider protocol here / how to debug well.