Description

This is a re-entry of a previous issue: terraform-aws-modules/terraform-aws-lambda#263 (comment)

The original issue still exists, and I would like to submit the suggested fix.

The resource "aws_lambda_function_event_invoke_config" "this" gets fired twice, in quick and consecutive order, and, for our setup, leads to issues with concurrent updates on the Lambda.

• ✋ I have searched the open/closed issues and my issue is not listed.

⚠️ Note

Before you submit an issue, please perform the following first:

1. Remove the local .terraform directory (! ONLY if state is stored remotely, which hopefully you are following that best practice!): rm -rf .terraform/
2. Re-initialize the project root to pull down modules: terraform init
3. Re-attempt your terraform plan or apply and check if the issue still persists

Versions

Terraform v1.3.7
on darwin_arm64

provider registry.terraform.io/hashicorp/aws v4.54.0
provider registry.terraform.io/hashicorp/external v2.2.3
provider registry.terraform.io/hashicorp/local v2.3.0
provider registry.terraform.io/hashicorp/null v3.2.1
Module: terraform-aws-modules/lambda/aws

Reproduction Code [Required]

1. We have a main.tf that makes calls to the same (custom) module, three times.

2. Our custom module calls terraform-aws-modules/lambda/aws and configures it with create_async_event_config = true, which is sufficient for the defaults in the variables.tf to come into play and trigger a call of aws_lambda_function_event_invoke_config.

3. This resource, aws_lambda_function_event_invoke_config, will use locals.qualifiers to make two calls via a for_each, in quick succession, once for current_version and once for unqualified_alias.

4. This leads to the following error message, printed:

│ Error: error putting Lambda Function Event Invoke Config (tracking-enrichment-stage-search-enriched-to-aurora:$LATEST): ResourceConflictException: The EventInvokeConfig for function arn:aws:lambda:eu-central-1:<ACCOUNT_ID>:function:tracking-enrichment-stage-search-enriched-to-aurora:$LATEST could not be updated due to a concurrent update operation.
│ {
│   RespMetadata: {
│     StatusCode: 409,
│     RequestID: "6768fc9b-15b2-4fc2-ab60-bbb836d617d4"
│   },
│   Message_: "The EventInvokeConfig for function arn:aws:lambda:eu-central-1:<ACCOUNT_ID>:function:tracking-enrichment-stage-search-enriched-to-aurora:$LATEST could not be updated due to a concurrent update operation.",
│   Type: "User"
│ }
│
│   with module.search_enriched_to_aurora.module.lambda_enriched_to_aurora.aws_lambda_function_event_invoke_config.this["current_version"],
│   on .terraform/modules/search_enriched_to_aurora.lambda_enriched_to_aurora/main.tf line 166, in resource "aws_lambda_function_event_invoke_config" "this":
│  166: resource "aws_lambda_function_event_invoke_config" "this" {

Expected behavior

The calls should be made in an order that doesn't cause concurrent updates.

Actual behavior

The same Lambda is modified twice, at the same time.

Additional context

A previous suggested fix was discussed here:
terraform-aws-modules/terraform-aws-lambda#263 (comment)

Description

Adding new VPC endpoints to an existing VPC using the last version of the vpc-endpoints module published on 11-Jan. I'm still getting the same error as I before mentioned (terraform-aws-modules/terraform-aws-vpc#650 (comment))

Versions

• Terraform:

$ terraform -version
Terraform v0.13.4

• Provider(s):

 $ terraform providers -version
+ provider registry.terraform.io/hashicorp/aws v4.8.0

• Module:
  https://github.com/terraform-aws-modules/terraform-aws-vpc/blob/master/modules/vpc-endpoints/main.tf

Reproduction

Steps to reproduce the behavior:

1. add one or more vpc endoints, like:

   service_catalog = {
      service             = "servicecatalog"
      tags                = { Name = "servicecatalog-vpc-endpoint" }
      private_dns_enabled = true
    },

    codecommit = {
      service             = "codecommit"
      tags                = { Name = "codecommit-vpc-endpoint" }
      private_dns_enabled = true
    },

    secret_manager = {
      service             = "secretsmanager"
      tags                = { Name = "secretsmanager-vpc-endpoint" }
      private_dns_enabled = true
    }

2. The vpc endpoints should be attached to an specific SG
3. Run terraform plan

Code Snippet to Reproduce

Actual behavior

After terraform plan, I'm still getting:

Error: Invalid index

  on .terraform/modules/vpc_endpoint/nested/vpc_endpoint_nested/main.tf line 21, in resource "aws_vpc_endpoint" "this":
  21:   service_name      = data.aws_vpc_endpoint_service.this[each.key].service_name
    |----------------
    | data.aws_vpc_endpoint_service.this is object with 9 attributes
    | each.key is "service_catalog"

The given key does not identify an element in this collection value.

ERRO[0045] 1 error occurred:
	* exit status 1

where our modules/vpc_endpoint/nested/vpc_endpoint_nested/main.tf is same as https://github.com/terraform-aws-modules/terraform-aws-vpc/blob/master/modules/vpc-endpoints/main.tf

using the for_each solution given in the commit 19fcf0d

Terminal Output Screenshot(s)

stream arn in output seems incorrect

https://github.com/terraform-aws-modules/terraform-aws-dynamodb-table/blob/4e2c8ec638d03276038766afa24cdca41453ef67/outputs.tf#L13

shouldn't this be var.stream_enabled ? try(aws_dynamodb_table.this[0].id, aws_dynamodb_table.autoscaled[0].stream_arn, "") : null

var.stream_enabled ? try(aws_dynamodb_table.this[0].stream_arn, aws_dynamodb_table.autoscaled[0].stream_arn, "") : null

Is your request related to a new offering from AWS?

yes! gp3 support is available in provider 3.25 and later.

Is your request related to a problem? Please describe.

I'd like to be able to enable gp3 volume type for the root_block_device (or any volume) on instances.

Describe the solution you'd like.

Ideally, updating the supported provider version to support gp3. However, I recognize updating to provider versions is a big deal, but is there any possibility of this happening in the future or should I move on to another module for the time being?

Describe alternatives you've considered.

Using other modules is all I could really think of here.

Additional context

module.ec2.aws_instance.this[0]: Refreshing state... [id=i-081a00cce42c2fa77]

Error: expected root_block_device.0.volume_type to be one of [standard io1 gp2 sc1 st1], got gp3

Description

consider this snippet:

module "appconfig" {
  source  = "terraform-aws-modules/appconfig/aws"
  version = "~> 1.0"

  name                                = "some-name"
  description                       = "AppConfig hosted configuration for some-name"
  config_profile_name               = title(var.environment)
  create_deployment_strategy        = false
  deployment_strategy_id            = "AppConfig.AllAtOnce"

  environments = {
    "${var.environment}" = {
      name        = "${title(var.environment)}"
      description = "${title(var.environment)} environment"
    }
  }

  use_hosted_configuration           = true
  hosted_config_version_content_type = "application/json"
  hosted_config_version_content      = file("${path.module}/configs/${var.environment}/config.json")
  
  tags = var.tags
}

• [v] ✋ I have searched the open/closed issues and my issue is not listed.

Versions

• Module version [Required]: 1.1.4 (note - this will reproduce on 2.0.0 as well)

Reproduction Code [Required]

see above

Steps to reproduce the behavior:
run init and plan, examine the output

Expected behavior

Expecting the deployment step to take place.

Actual behavior

Deployment is not in the plan

Terminal Output Screenshot(s)

Additional context

This issue was introduced in the 1.1.4 version via this PR: terraform-aws-modules/terraform-aws-appconfig#7
The fix should take into account the use_hosted_configuration flag and allow the code in the aws_appconfig_deployment resource to run even if deployment_configuration_version is not set.

resource "aws_ec2_tag" "default_example" {

count = var.create_vpn_connection && local.tunnel_details_not_specified ? 1 : 0

resource_id = aws_vpn_connection.default[0].transit_gateway_attachment_id
key = "Name"
value = "local.name_tag"
}

resource "aws_ec2_tag" "tunnel_example" {

count = var.create_vpn_connection && local.create_tunnel_with_internal_cidr_only ? 1 : 0

resource_id = aws_vpn_connection.tunnel[0].transit_gateway_attachment_id
key = "Name"
value = local.name_tag
}

resource "aws_ec2_tag" "preshared_example" {

count = var.create_vpn_connection && local.create_tunnel_with_preshared_key_only ? 1 : 0

resource_id = aws_vpn_connection.preshared[0].transit_gateway_attachment_id
key = "Name"
value = local.name_tag
}

resource "aws_ec2_tag" "tunnel_preshared_example" {

count = var.create_vpn_connection && local.tunnel_details_specified ? 1 : 0

resource_id = aws_vpn_connection.tunnel_preshared[0].transit_gateway_attachment_id
key = "Name"
value = local.name_tag
}

The input parameter: subsription_filter_policy has a typo. It's missing a c :

so just need to change subsription_filter_policy to subscription_filter_policy

Is your request related to a new offering from AWS?

N/A

Is your request related to a problem? Please describe.

Each repository has five workflow codes(e.g. lock.yml, pr-title.yml, etc.). These workflows consist of the same code. If the workflow requirements change, the workflow for each repository must be changed individually. This makes maintenance difficult and can lead to human error.

Describe the solution you'd like.

By abstracting into reusable workflows, we can simplify redundant workflows.

Example

name: 'Lock Threads Template'

on: workflow_call

jobs:
  lock:
    runs-on: ubuntu-latest
    steps:
    # ...

name: 'Call Lock Threads'

on:
  schedule:
    - cron: '50 1 * * *'

jobs:
  call-lock:
    uses: terraform-aws-modules/.github/.github/workflow-templates/lock.yml
    with:
      secrets: inheirt

References

• https://docs.github.com/en/actions/using-workflows/reusing-workflows
• https://github.com/actions/reusable-workflows

Describe alternatives you've considered.

N/A

Additional context

If there's nothing wrong with this issue, can I work on it?

Hello,

I am facing an issue with SQS standard queue. In SQS, as we know whenever a message is failed, it is stored in a dead letter queue (dlq) but the issue is when sqs is retrying to process the failed message, it is storing the same failed message again in the DLQ which causes the problem of duplicacy.

So, is there any way to remove duplicacy or a way such that if a message is retried it will not stored in the dead letter queue again if it is already there in the dead letter queue?