Hello. Are there any good workarounds for depends_...
# terraform
r
Hello. Are there any good workarounds for depends_on in data resources and cases like https://github.com/hashicorp/terraform-provider-aws/issues/29421 ? In my setup, I am trying to create a terraform aws-sso module, which not only creates AWS PS and assigns to accounts, but also creates an AD group, triggers AWS SCIM sync, and then using data resource finds the corresponding AWS SSO group id via its name. The issue is that data resource needs to depend on the AD SCIM trigger resource, which results in constant "known after apply" AWS Permission Set account assignment resource recreation due to how data resources work. I know that I can use ignore_changes lifecycle, or even separate the module into two technically, but just curious if anyone faced something similar and has some other approaches.
l
known after apply issues are not related to
depends_on
, but instead to using the unknown value as the key in the
for_each
expression. the solution for that is "don't do that" 🙂 instead, use a known value as the key for the expression, and then use
each.value...
for the attribute you want
🙏 1
p
This is a known Terraform core behaviour. When a data source has
depends_on
pointing to a resource with pending changes, Terraform defers the read to apply time, which then cascades into 'known after apply' on anything downstream. For your SSO/SCIM case the cleanest workaround short of splitting the module is to avoid the data source lookup entirely. If you're creating the AD group in the same config, you likely already have the group name as a known value. You can pass it directly as a variable instead of looking it up via data source. The SCIM sync just needs to complete before the assignment, which
depends_on
handles, but the group ID lookup doesn't need to be a data source if the value is already in your config.
ignore_changes
on the assignment resource works too but it's a footgun. You'll miss real changes down the line. Splitting the module is more surgical but the two-run requirement gets old fast. There's no clean fix at the provider level. This is Terraform core behaviour that HashiCorp closed as by-design.