Using updated attributes during planning phase

I have a provider resource that retrieves login information from an azure keyvault secret data source. Somewhat like this:

data "azurerm_key_vault" "kv" {
  name                = "MyKeyVualt"
  resource_group_name = "My-RG"
}

data "azurerm_key_vault_secret" "mysecret" {
  name         = "my-secret"
  key_vault_id = data.azurerm_key_vault.kv
}

resource "my_provider" "my_resource" {
  username = "user"
  password = data.azurerm_key_vault_secret.mysecret.value
}

If we ignore for now that the azurerm_key_vault_secret data source will not read a new version of the secret; if the value of the data source changes, how can I access this new value in my provider’s password attribute during the planning phase? I’m currently getting the value stored in the terraform state, which is now invalid. Without the new password, I can’t log in to the backend and get the current values from the backend resource, and actually my provider now fails the read with an unauthorized error.

I’m now really worried about this; this feels like a serious design flaw if true. I’ve yet to do my own testing, as we have the exact same scenario (but for a private provider’s credentials), but I’d like a statement from HashiCorp on this.

bump Does anyone in the know have any info on this?

The way Terraform works, by my recollection, is to refresh the state first, including reading data sources, then generate a plan. So you should already be getting the latest value during plan. I think (I’m not sure, a Terraform core engineer would know more) that the graph can sometimes make this complicated–e.g., a data source depending on a computed value of a resource may have a different behavior–but I’d imagine that depending on another data source wouldn’t trigger that. :thinking: I could be wrong, though. Even then, however, a practitioner should see “(value known after apply)” or whatever, not the old value. And I’m not sure what the SDK would surface during CustomizeDiff–I have some recollection that it may be a UUID, but I’m also suspicious that it may just be the empty value for that type. Could be wrong, though.

Are you trying to access the value in CustomizeDiff?