Terraform: Unexpected ) syntax error is always reported to be at 1:29

[mschuchard]

Terraform Version

0.11.7

Terraform Configuration Files

This holds true for any syntax error of this type, but here is a sample MCVE:

module "eks" {
  subnets = "${module.vpc.private_subnets)}"
}

Expected Behavior

terraform plan and terraform validate report an accurate line and column information for a syntax error, or at least not an inaccurate one (no line and column information may even be preferable here).

Actual Behavior

The line and col information for a ) occurring where a } should be is always reported to be at 1:29, even when that line and column do not actually exist (such as in the above MCVE).

Sample output is as follows:

Error: Error loading /path/to/main.tf: Error reading config for eks: parse error at 1:29: expected "}" but found ")"

Steps to Reproduce

terraform plan or terraform validate

How Did I Actually Run Into This Problem?

I had the subnets as two combined arrays within a function before dropping one of the arrays and forgot to remove the ) at the end of the function invocation to combine the arrays, so I get that a lot of people are not likely encountering this bug. For those of us who remember to eliminate a leading ( and forget the trailing ) and our config file is 100+ lines, well that can be frustrating.

[apparentlymart]

Hi @mschuchard! Sorry for this useless error message.

In the current version of Terraform, the interpolation expressions within a string are parsed separately from the overall configuration structure and so that source reference is relative to the string itself, rather than the configuration as a whole.

Fortunately, the next major release of Terraform will include a number of improvements to the configuration language which start by combining the two different parts of Terraform's language into a single parser, and that should address this problem.

We'll leave this open for now as a reminder to check on this as we do our prep for that release. This particular one will definitely be fixed by that change, but since the work for that release is not yet on master this issue will serve as a reminder to us to verify it once it's merged.

Thanks for reporting this!

[mschuchard]

Thanks @apparentlymart; I did see the article on the HCL enhancements the other day and am looking forward to those indeed.

[apparentlymart]

I tried your example with a build from our development branch this morning, and indeed we do get a much better error message for this example:

We'll still check this again as part of prepping the release to make sure nothing regressed it (unlikely at this point, since active development on the parser completed a while back), but this result is encouraging.

[apparentlymart]

Hi again, @mschuchard!

The changes I mentioned before are now landed in master ready to be included in the forthcoming v0.12.0 release. I verified again with v0.12.0-alpha2 and got exactly the same error message as I showed before, so I'm going to close this out now.

Thanks again for reporting this!

[hashibot[bot]]

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.