[Bug]: aws_servicequotas_service_quota incorrectly attempts to send a new request on 2nd run

[acaban-nuharbor]

Terraform Core Version

1.1.7

AWS Provider Version

2.11.4

Affected Resource(s)

When using the following resource, the first run completes successfully, but the second run attempts to send a request and fails:

resource "aws_servicequotas_service_quota" "fargate_vcpu_increase" {
  quota_code   = "L-3032A538"
  service_code = "fargate"
  value        = 16
}

A note about my configuration: The service quota is already set to 30 in my AWS account before the first terraform run.

Expected Behavior

Expecting that the second run works exactly like the first run: it recognizes that the service quota change need not be performed.

Actual Behavior

In the first run, I get the following output:

  # module.service_quotas.aws_servicequotas_service_quota.fargate_vcpu_increase will be created
  + resource "aws_servicequotas_service_quota" "fargate_vcpu_increase" {
      + adjustable     = (known after apply)
      + arn            = (known after apply)
      + default_value  = (known after apply)
      + id             = (known after apply)
      + quota_code     = "L-3032A538"
      + quota_name     = (known after apply)
      + request_id     = (known after apply)
      + request_status = (known after apply)
      + service_code   = "fargate"
      + service_name   = (known after apply)
      + usage_metric   = (known after apply)
      + value          = 16
    }
Plan: 1 to add, 1 to change, 0 to destroy.

. . .

Apply complete! Resources: 1 added, 1 changed, 0 destroyed.

Now, I run terraform again, and get the following error:

Terraform will perform the following actions:

  # module.service_quotas.aws_servicequotas_service_quota.fargate_vcpu_increase will be updated in-place
  ~ resource "aws_servicequotas_service_quota" "fargate_vcpu_increase" {
        id            = "fargate/L-3032A538"
      ~ value         = 30 -> 16
        # (8 unchanged attributes hidden)
    }

. . .

Plan: 0 to add, 2 to change, 0 to destroy.

. . .

│ Error: requesting Service Quota (fargate/L-3032A538) increase: IllegalArgumentException: You must provide a quota value greater than the current quota value
│ 
│   with module.service_quotas.aws_servicequotas_service_quota.fargate_vcpu_increase,
│   on ../service_quotas/main.tf line 6, in resource "aws_servicequotas_service_quota" "fargate_vcpu_increase":
│    6: resource "aws_servicequotas_service_quota" "fargate_vcpu_increase" {
│ 

Relevant Error/Panic Output Snippet

No response

Terraform Configuration Files

N/A

Steps to Reproduce

1. Have a previously configured AWS account with Fargate vCPU resources set to 30
2. Run terraform with aws_servicequotas_service_quota resource for quota_code L-3032A538 & service_code fargate setting value to 16
3. Note that the run succeeds
4. Run it again with no changes
5. The command fails

Debug Output

No response

Panic Output

No response

Important Factoids

No response

References

No response

Would you like to implement a fix?

None

[github-actions[bot]]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[rdark]

I did a bit of digging into this one as we had an RDS quota that was constantly re-applied.

With debug mode on I saw:

[DEBUG] provider.terraform-provider-aws_v4.67.0_x5: HTTP Response Received: @module=aws aws.operation=GetServiceQuota http.response_content_length=439 http.status_code=200 tf_provider_addr=registry.terraform.io/hashicorp/aws tf_resource_type=aws_servicequotas_service_quota aws.region=eu-west-2 http.response.header.content_type=application/x-amz-json-1.1 tf_mux_provider=*schema.GRPCProviderServer tf_req_id=ec5c395f-79e7-e7a7-d6d8-47a1f953efe8 tf_rpc=ReadResource aws.service="Service Quotas" http.response.body="{"Quota":{"Adjustable":true,"ErrorReason":{"ErrorCode":"DEPENDENCY_ACCESS_DENIED_ERROR","ErrorMessage":"You don’t have access to rds:DescribeAccountAttributes"},"GlobalQuota":false,"QuotaAppliedAtLevel":"ACCOUNT","QuotaArn":"arn:aws:servicequotas:eu-west-2:111111111111:rds/L-7B6409FD","QuotaCode":"L-7B6409FD","QuotaName":"DB instances","ServiceCode":"rds","ServiceName":"Amazon Relational Database Service (Amazon RDS)","Unit":"None"}}" http.response.header.x_amzn_requestid=0cce48da-2f8e-4f31-8d53-478fddd88700 @caller=github.com/hashicorp/aws-sdk-go-base/v2/awsv1shim/v2@v2.0.0-beta.26/logger.go:138 aws.sdk=aws-sdk-go http.duration=70 http.response.header.date="Thu, 21 Sep 2023 09:19:43 GMT" timestamp=2023-09-21T10:19:43.191+0100

So the underlying issue was that we didn't have the rds:DescribeAccountAttributes action on the policy.

In the provider code it first sets up the quota value with the default value

Then, as some quotas are weird and don't report values, the provider attempts to fetch the actual quota and set it if it didn't return an error.

Seems like we need some additional error handling here; if there is a missing IAM permission then it should throw an error rather than just silently swallowing it