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
+1
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.
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.
Hit the issue same day trying to update the kinesis source mapping settings.
Most helpful comment
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.