The event source and function provided mapping already exists. Please update or delete the existing mapping with UUID

[MatteoGioioso]

Description:
I am trying to implement Dynamodb streams and a trigger for lambda

 myFunction:
    Type: AWS::Serverless::Function
    Properties:
      Policies:
        - AWSLambdaBasicExecutionRole
        - DynamoDBCrudPolicy:
            TableName: !Ref TableName
        - DynamoDBStreamReadPolicy:
            TableName: !Ref TableName
            StreamName:
              !Select
                - 2
                - !Split
                  -  "/"
                  - Fn::ImportValue:
                      !Sub ${TableName}-streams-arn
      CodeUri: bin/
      Handler: myFunctions
      Events:
        dynamodb:
          Type: DynamoDB
          Properties:
            Stream:
              Fn::ImportValue: !Sub ${TableName}-streams-arn
            StartingPosition: LATEST
            BatchSize: 10

The first deployment was successful, however after adding the DynamoDBStreamReadPolicy and changed StartingPosition from TRIM_HORIZON to LATEST I got the following error:

The event source arn (" arn:aws:dynamodb:.../stream/... ") and function (" myFunction-...") provided mapping already exists. Please update or delete the existing mapping with UUID xxxx-xxxx-xxx-xxx (Service: AWSLambda; Status Code: 409; Error Code: ResourceConflictException; Request ID: xxxx-xxxxxxx-xxxx-xxx)

Observed result:
Error

Expected result:
Probably error, but at this point I did not find any explanation

PS: as my understanding once the event mapping is created must be replaced or deleted? If yes why it says "Please update or delete"? If now I want to change the mapping configuration do I need to remove it, deploy, add it again and redeploy?

Thanks

[elembie]

+1

[shearn89]

For future Googlers: I had this issue, and it was because there was a manually-created trigger hanging around that wasn't deleted with my stack. Using the CLI to delete by UUID, or going to SQS -> the queue -> Lambda triggers should have let me find it.

[MatteoGioioso]

Ok, this is a long standing bug with Cloudformation.
Similar happening with Kinesis and it was already spotted in 2018 on the serverless framework.
This is a minimal reproducible case with kinesis: https://github.com/MatteoGioioso/sls-event-source-mapping-bug
You just need to change startingPosition from TRIM_HORIZON to LATESTto trigger the bug.

[cli402]

Hit the issue same day trying to update the kinesis source mapping settings.

[bissli82]

Please fix, same issue here!

[myoung34]

I also ran into and fixed this by calling aws lambda list-event-source-mappings to find the orphaned mapping then aws lambda delete-event-source-mapping --uuid {uuid} to remove it

[lukaboljevic]

Sorry for commenting on an old post. I just ran into this issue.

I also ran into and fixed this by calling aws lambda list-event-source-mappings to find the orphaned mapping then aws lambda delete-event-source-mapping --uuid {uuid} to remove it

This solved the issue for me as well.

Before trying it out, I tried updating the event source mapping directly through the AWS console, but it would not let me, I would just get the same error again. The solution myoung34 recommended seems like the only viable option to solve this. To anyone who comes across this post while Googling, I recommend you try it out, at least until the bug is addressed.

[hoffa]

Thanks all for the input, very informative.

I'm able to reproduce this with a pure CloudFormation template:

Resources:
  MyTable:
    Type: AWS::DynamoDB::Table
    Properties:
      BillingMode: PAY_PER_REQUEST
      KeySchema:
        - AttributeName: MyAttribute
          KeyType: HASH
      AttributeDefinitions:
        - AttributeName: MyAttribute
          AttributeType: S
      StreamSpecification:
        StreamViewType: KEYS_ONLY
  MyFunction:
    Type: AWS::Lambda::Function
    Properties:
      Runtime: python3.8
      Handler: index.handler
      Role: !GetAtt MyFunctionRole.Arn
      Code:
        ZipFile: |
          def handler(event, context):
              return {'body': 'Hello World!', 'statusCode': 200}
  MyFunctionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Statement:
          - Action:
              - sts:AssumeRole
            Effect: Allow
            Principal:
              Service:
                - lambda.amazonaws.com
        Version: "2012-10-17"
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
        - arn:aws:iam::aws:policy/service-role/AWSLambdaDynamoDBExecutionRole
  MyFunctionMyTableEvent:
    Type: AWS::Lambda::EventSourceMapping
    Properties:
      EventSourceArn: !GetAtt MyTable.StreamArn
      FunctionName: !Ref MyFunction
      StartingPosition: TRIM_HORIZON

That template will deploy fine.

But as @MatteoGioioso mentioned, if you change StartingPosition from TRIM_HORIZON to LATEST and deploy again, you'll get the error:

The event source arn ([...]) and function ([...]) provided mapping already exists. Please update or delete the existing mapping with UUID [...]

[jayfry1077]

This is still occurring just happened to me today.

[jfuss]

From the original error and #1320 (comment) this is an issue with Lambda directly. SAM doesn't have much control over this and can't even detect it because we don't keep state. I will try to track down some things with Lambda and see what I can communicate back to the community here.

Updating labels (removing bug because this is a Lambda Service issue).

[jeff1evesque]

I was able to execute the following manually, then the corresponding CloudFormation template succeeded:

UUID=$(aws lambda list-event-source-mappings --function-name HotDogs --query 'EventSourceMappings[0].UUID' --output text 2>/dev/null)
aws lambda delete-event-source-mapping --uuid "$UUID"

However, I would advocate that the bug be resolved internally with AWS engineers. That way we don't have to do one-off scripts/commands to ensure something expected to work correctly, actually works.

[oleksandrsemak]

I have the same issue with terraform and aws_lambda_event_source_mapping with self_managed_event_source

[drnorton83]

The issue also happens with AWS CDK (v1.134.0) generated CloudFormation templates. When the Lambda event source is a SQS queue.

[eyalroth]

This problem also reproduces when trying to move an SQS mapping from a function's Events:

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    Events:
      Queue:
        Type: SQS
        Properties:
          Queue: !GetAtt MyQueue.Arn

to a standalone AWS::Lambda::EventSourceMapping:

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    ...

MyFunctionSqsMapping:
  Type: AWS::Lambda::EventSourceMapping
  Properties:
    EventSourceArn: !GetAtt MyQueue.Arn
    FunctionName: !GetAtt MyFunction.Arn

SAM/CloudFormation attempts at creating the new mapping before deleting the old one. I'd expect it to realize it needs to perform these actions in the opposite order.

This problem seems to plague other event mapping types as seen in serverless/serverless#4471

[tbenbrahim]

2 and half years later and still running into that problem. With a Lambda with an event source mapping in a SAM template. simply adding a layer to the lambda triggered this error.
I am sure doing a lot of ClickOps today for something that is supposedly IAC.

[AlvinMengCao]

Removing the mapping solves the issue, but it causes the data loss. And today my experience is even stranger. Our pipeline failed due to this error, when we tried to add DLQ to the Lambda function. The Lambda already has Kinesis as a trigger. After manually removing the event mapping, CFN deployment passed. However, Kinesis won't trigger the Lambda. We got alarm everywhere. I need to manually remove the Kinesis trigger from the console, and add it back.

This happened in our gamma stack, which is relatively acceptable. I couldn't imagine what to do if this is in prod.

[sunnygoel87]

I also ran into and fixed this by calling aws lambda list-event-source-mappings to find the orphaned mapping then aws lambda delete-event-source-mapping --uuid {uuid} to remove it

I also faced this issue while deploying the Terraform code 2nd time. Do we need to get rid of existing mapping everytime we make any change related to mapping ?

[madhug-nadig]

Is there an ETA on the fix?

[normand1]

I ran into this error today when trying to subscribe a single SQS queue to listen to multiple SNS Topics. Each of these SQS Queues are mapped to a single lambda function. This is a valid SAM Template, but I receive an error that Cloud Formation is trying to create duplicate mappings and the deployment fails.

[hoffa]

As mentioned in #1320 (comment) (and others), this has to do with the underlying resource, and can be reproduced without SAM. SAM only transforms the template into CloudFormation, but doesn't otherwise handle the provisioning.

The issue is that changes to the property requires replacement, but due to how CloudFormation handles changes that require replacement (typically by first creating the new resource and then deleting the old one), it'll try to create two event source mappings from the same resource, which Lambda doesn't allow.

I've routed this issue internally.

[jomach]

@hoffa I'm hitting the same. Can you please re-open and publish the status from "I've routed this issue internally." ?

[jomach]

Use the aws cli as: aws lambda delete-event-source-mapping to delete the uuid that is "broken" then re-apply the cloud formation stack
See: https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-event-source-mapping.html

[harekumar]

Hi Guys,

I ran into the same issue when I tried to register a SQS->lambda trigger. 1st deployment is successful but in the next deployment if there is any change in the configuration of lambda, SQS or event_source_mapping then it fails with the following error.

An event source mapping with SQS arn ("queue-arn") and function ("lambda-function") already exists. Please update or delete the existing mapping with UUID

So, my question is have we already fixed this issue in the latest cdk version? I'm currently, using aws-cdk-lib==2.17.0

Any recommendations on how to handle it gracefully?