does not have attribute result.foo

[aep]

Terraform v0.9.8

${data.external.foo.result.bla}

will not actually work

* data.template_cloudinit_config.border: Resource 'data.external.border-gw-key' does not have attribute 'result.priv' for variable 'data.external.border-gw-key.result.priv'

the correct usage appears to be

${lookup(data.external.foo.result, "bla")}

it would be great if the documentation mentioned that. Took me quite some hairpulling to figure that out, as everything i found googling appears to be using result.attr

[madmod]

Please fix this. It has cost me a lot of time. Thanks for your hard work! 😃

[ebarault]

I reproduced this bug when using node as the program param in the external provider.

However using bash as the program I do have another module where using directly ${data.external.foo.result} works.

[daryl-mcmillan]

I don't know exactly when it works and when it doesn't, but I'm seeing ${data.external.foo.result.bla} work in some cases. I'm also seeing that on the runs that fail to access result properties directly my external program is never invoked.

[JojoJgeorge]

Hi there. Apologies if this is long resolved but;

For info I am also receiving this error when using PowerShell as an external data source on terraform v0.11.3, external provider v1.0.0. Strangely enough this issue only occurred after a flush of the local .terraform cache/state after a destroy (testing to ensure module builds from scratch). Prior to this it was actually working using the ${data.external.foo.result.property} syntax, now will only work using the ${lookup(data.external.foo.result, "property"} syntax.

Happy it now works though, @aep thanks for preventing a headache!

[danieladams456]

I think I figured out what's going on here. It will happen when the external provider is not run at plan time, which is caused by having a computed value as one of the inputs. You can see the full scenario in #19.

It is working as intended per hashicorp/terraform#17034. The reader side just can't know the next level property exists since output is marked as computed. But yes, like @aep said, documentation of this situation would be nice.