Syntax errors are unnecessarily difficult to debug.

[RichardBronosky]

As a new evaluator, possible adopter, of Terraform, I'm finding the learning process to be slow, arduous, and infuriating. The error messages do not tell you what line (or even what block) the error was encountered on. Consequently I spent hours trying to find the right way to join( after adding count = 2 but the problem I was encountering was in the provisioner block that previously worked.

Also, I find it very off putting that my feedback loop is 3+ minutes between saving a change to my config and seeing the result of a retest. I think more should be done to evaluate syntax during a terraform plan.

Ultimately, we need to:

1. 'fail fast'
2. not pass (validate and plan) when you're going to fail (apply), and
3. tell the user what is known about where the error occurred

Terraform Version

Terraform v0.8.4

Terraform Configuration Files

resource "aws_instance" "secondary" {
  count = 2
…
  provisioner "local-exec" {
    command = "echo ${aws_instance.secondary.private_ip} | tee -a ip_address.txt"
  }
}

output "secondary" {
  value = "${join(" ", aws_instance.secondary.*.private_ip)}"
}

Debug Output

Error applying plan:

1 error(s) occurred:

* Resource 'aws_instance.secondary' not found for variable 'aws_instance.secondary.private_ip'

[mattlqx]

+1

Without line numbers and columns pointing back to the .tf code, finding problems (either syntactical or as a result of a resource failing) can be tedious and difficult.

[apparentlymart]

I completely agree about how unhelpful these error messages tend to be!

I've been making gradual progress towards making the source position information available more readily so that Terraform can report positions correctly, but there's a few more layers to work through before this will make it all the way up to the surface.

(Existing work on this path is hashicorp/hil#32, hashicorp/hcl#171; remaining work is to make Terraform use the interface exposed in the latter to record source positions correctly and then expose the now-correct source locations more consistently across all parsing- and evaluation-related error messages.)

[RichardBronosky]

Discovering export TF_LOG=TRACE helped tremendously. However, I won't have that set until AFTER there is a problem.

[apparentlymart]

Hi all! Sorry for the long silence here.

Terraform v0.12.0 will include much better error messages in many cases. So far we've introduced a new error message renderer that includes source location information where available, and updated many of the error messages Terraform generates to be more helpful. For example:

Error: Reference to undeclared input variable

  on error-messages.tf line 2, in resource "aws_instance" "secondary":
   2:   ami           = var.ami

An input variable with the name "ami" has not been declared. This variable can
be declared with a variable "ami" {} block.

Since there are many different error messages across Terraform Core and all of the providers, there will inevitably be some suboptimal error messages remaining when we release v0.12.0 final, but we'll address those iteratively as we find them. Since this issue is about error messages in general rather than about any specific error message, I'm going to consider the new model for errors and warnings with source location information as the solution to this issue and expect that we'll make new issues for specific remaining poor error messages later on.

Since this work is already in master and included in the experimental alpha1 release I'm going to close out this issue. Thanks for reporting this!

[ghost]

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.