Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confusing error message from the S3 backend with empty-string argument values #29557

Closed
Tracked by #33687
faridnsh opened this issue Sep 10, 2021 · 3 comments
Closed
Tracked by #33687

Comments

@faridnsh
Copy link
Contributor

Terraform Version

Terraform v1.0.6
on darwin_amd64
+ provider registry.terraform.io/hashicorp/aws v3.58.0

Terraform Configuration Files

data "terraform_remote_state" "test" {
  backend = "s3"
  config = {
    bucket = ""
    key = ""
    region = "eu-west-1"
  }
}

Debug Output

https://gist.github.com/alFReD-NSH/517e76e09d9e6733174f76b4d37d9a5f

Crash Output

│ Error: InvalidParameter: 2 validation error(s) found.
│ - minimum field size of 1, GetObjectInput.Bucket.
│ - minimum field size of 1, GetObjectInput.Key.

Expected Behavior

The error should state which file and which line or which resource/datasource it came from.

Actual Behavior

The error does not state which file and which line or which resource/datasource it came from.

Steps to Reproduce

  1. terraform init
  2. terraform apply
@faridnsh faridnsh added bug new new issue not yet triaged labels Sep 10, 2021
@apparentlymart
Copy link
Contributor

Thanks for reporting this, @alFReD-NSH!

Based on the terminology in that error message it seems like this is something being returned from the underlying AWS SDK rather than directly by Terraform, so I suppose the S3 backend must be just passing the message through verbatim without interpreting it into Terraform terminology first. (I'm assuming that GetObjectInput here is referring to the SDK type s3.GetObjectInput, which we're presumably using as part of the implementation of the S3 backend.)

You're right that it's weird that this error isn't at least being annotated by the source location of the data resource that caused it. Along with that, it also seems like the S3 backend's configuration processing logic is missing some validation rules to detect if the bucket and key arguments have suitable values, so that it could then present the problem in terms of the S3 backend's arguments rather than in terms of implementation details of the backend.

If the S3 backend were handling this validation itself then I think it should be possible to return a pair of higher-quality error messages referring directly to the problematic expressions:

Error: Invalid S3 bucket name

  on example.tf line 4, in data "terraform_remote_state" "test":
    4:     bucket = ""

An S3 bucket name must be [whatever are the AWS-documented validation rules for S3 bucket names].


Error: Invalid S3 object key

  on example.tf line 5, in data "terraform_remote_state" "test":
    5:     key = ""

An S3 object key must be [whatever are the AWS-documented validation rules for S3 keys].

It's possible that this might run into some unusual extra challenges because for terraform_remote_state in particular we're dealing with the validation of backend arguments inside the validation of resource arguments, and so we have an extra level of indirection on the source locations than we usually do and we might not be able to get quite to the ideal I've shown above without some refactoring, but hopefully we can find a suitable compromise to at least explain the problems in Terraform-relevant terminology and associate the message at least with the data block as a whole, even if not the specific arguments here.

Thanks again!

@apparentlymart apparentlymart added backend/s3 enhancement and removed bug new new issue not yet triaged labels Sep 10, 2021
@apparentlymart apparentlymart changed the title Terraform remote state data source with invalid S3 config results in bad error message Confusing error message from the S3 backend with empty-string argument values Sep 10, 2021
@gdavison
Copy link
Contributor

This has been fixed at some point since the issue was filed

@gdavison gdavison closed this as not planned Won't fix, can't repro, duplicate, stale Aug 22, 2023
Copy link
Contributor

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 12, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants