Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change on non-computed attributes does not properly delegate to data source #15958

Closed
synthdnb opened this issue Aug 30, 2017 · 4 comments
Closed

Comments

@synthdnb
Copy link

I made small terraform file to reproduce this issue.

resource "aws_route53_record" "test" {
  zone_id = "ZONE_ID"
  name    = "test1.domain.com"
  type    = "A"
  ttl     = "300"
  records = ["1.2.3.4"]
}

data "template_file" "tpl" {
  template = "$${url}"

  vars {
    url = "${aws_route53_record.test.name}"
  }
}

resource "aws_s3_bucket_object" "object" {
  bucket  = "SOME_BUCKET_NAME"
  key     = "SOME_KEY"
  content = "${data.template_file.tpl.rendered}"
}

When I change name on aws_route53_record.test to test2.domain.com, but template_file.tpl fails detect change on first apply. It detects change on next apply.

Using aws_route53_record.test.fqdn instead of name solves the problem in this case. It seems that name reads value from previous state since it is not a computed attribute, and fqdn works well since it is computed attribute and defers evaluation until apply.

Is this behavior intended? Even if this behavior is intended, I think enhancing documentation about this case may help everyone a lot.

@jbardin jbardin added the bug label Aug 30, 2017
@jbardin
Copy link
Member

jbardin commented Aug 30, 2017

Hi @synthdnb,

Thanks for the excellent bug report.
I think the issue might be that name forces a new resource, so the existing resource referenced when the datasource is refreshed is technically unchanged, and hasn't yet been marked as deposed. You might be able to work around this for now by using depends_on in the template_file, which forces a datasource to be refreshed after its dependencies, which should pick up the new resource.

@apparentlymart
Copy link
Contributor

The quirky behavior here would be addressed by the lifecycle change proposed in #17034.

@hashibot hashibot added the core label Aug 29, 2019
@hashibot
Copy link
Contributor

Hello! 🤖

This issue seems to be covering the same problem or request as #17034, so we're going to close it just to consolidate the discussion over there. Thanks!

@ghost
Copy link

ghost commented Sep 29, 2019

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Sep 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants