Allow augmenting resource errors with custom messages

[drewmullen]

Use Case

Looking for a way to augment the error message. To communicate extra information from the configuration.

Not suggesting this as a final proposal, but just an example, something as simple as the following may work:

lifecycle {
  failure_message = "some went wrong, you may need to request access to this resource type"
}

And that message could be added as a separate diagnostic attributed to the resource block in the configuration.

[jbardin]

Hi @drewmullen,

A single data source like this is intended to represent a resource known to exist outside of the management scope of the configuration, intentionally creating that resource within the config and then referencing it with a data source from the same configuration would explicitly be an anti-pattern we stress users avoid.

Functionally, the postcondition doesn't really work here, because Terraform cannot know why the data source returned an error. It could be because the resource didn't exist, or it could be because of a network problem, or invalid credentials, etc. Technically even if there is a self value instantiated for evaluation after that point, the self.name attribute would be unknown, and the postcondition would be skipped.

This is essentially the same problem as outlined in issues like #37166, #16380, #28617 and #30291.

Going forward, now that we have a defined way to fashion a plural data resource with the list resource mode, that could offer a way to base conditions on the number of resource values it returns.

[drewmullen]

intentionally creating that resource within the config and then referencing it with a data source from the same configuration would explicitly be an anti-pattern we stress users avoid.

To be clear, this is not what I was trying to represent. This was just meant to show an example of having config1, config2 where config2 relies on a resource existing from config1's apply. I can conceive of other ways catching a DS failure and providing a user specific error would be helpful in many other ways though

Technically even if there is a self value instantiated for evaluation after that point, the self.name attribute would be unknown, and the postcondition would be skipped.

perhaps another thought... what if instead of an explicit condition... you just add a field that catches a failure?

data "fake_user" "admin" {
  name = "admin"

  lifecycle { postcondition {
   catch_failure = true
   error     = "alert! no admin account! run the prior tf config with `terraform apply -target=../admin-create"
  }}
}

Going forward, now that we have a defined way to fashion a plural data resource with the list resource mode, that could offer a way to base conditions on the number of resource values it returns.

I suppose ill have to look deeper into this. The issue atm is 1. the list ds must exist, 2. i have to find a way to craft the list DS to find exactly 1 resource.

However, I understand your concerns and will let it go

[jbardin]

Thanks @drewmullen,

Rather than this being about the data source itself, and having a condition based on its state (or lack there of), I think what we're looking for here is to basically augment the error message. Since we have many issues about the complications around making data resources optionally succeed or fail, we can refine this to be more specifically about communicating extra information from the configuration.

Not suggesting this as a final proposal, but just an example, something as simple as the following may work:

lifecycle {
  failure_message = "some went wrong, you may need to request access to this resource type"
}

And that message could be added as a separate diagnostic attributed to the resource block in the configuration.