Existing Lambda used as SQS trigger failing when cdk deploy

[sacag]

I currently have the stacks deployed using the pre-cdk way i.e. using cloudformation templates. Now, I am using CDK to deploy and I am getting this error
An event source mapping with SQS arn (" ARN of the DLQ") and function (" ARN of lambda function used as a trigger for the DLQ ") already exists. Please update or delete the existing mapping with UUID 2d4bc5c5-9618-40ca-8b0e-799c2d4ec696 (Service: AWSLambda; Status Code: 409; Error Code: ResourceConflictException; Request ID: bfc49114-8929-4382-ad2c-7def9e6edd86)...any idea how to resolve it without deleting the lambda trigger?

Below is the code i have in C#

 MessageErrorProcessorLambdaFunction.AddEventSource(new SqsEventSource(MsgDeadLetterQueue.Queue, new SqsEventSourceProps
            {
                BatchSize = 1
            }));

I tried this too

new EventSourceMapping(this, $"{TopicIdentifier}-EventSourceErrProcessor-Id", new EventSourceMappingProps
            {
                BatchSize = 1,
                Enabled = true,
                EventSourceArn = MsgDeadLetterQueue.Queue.QueueArn,
                Target = MessageErrorProcessorLambdaFunction
            });

Same result

Environment

• **CLI Version :**1.31
• Framework Version:
• OS : Windows
• Language : C#

Other

---

This is 🐛 Bug Report

[sacag]

Hello @MrArnoldPalmer , any thoughts on how to resolve this issue?

[MrArnoldPalmer]

hey @sacag, So the stacks you deployed using the template are still deployed and you're trying to replicate them as-is using CDK?

The issue above is its trying to create a new event handler but it sees that one already exists. So the ID of the event handler being created is different than the existing one. You can try a couple of things.

1. deleting the existing event handler manually and redeploying the stacks
2. removing the event handler creation from your CDK code and seeing if the old one then gets deleted when you run cdk deploy and then adding it back and redeploying.

Is you code somewhere we can take a look or can you make a minimal reproduction so we can play around with it?

[sacag]

I did get around by doing #2 but that's not ideal. Shouldn't there be a way to check if the event handler exists then do not do anything or update it maybe when cdk deploy is executing?

[MrArnoldPalmer]

@sacag yeah migration from existing CFN stacks generally has a lot of gotchas like this. We have thought about it and have a tracking issue for an RFC to design a solution and started to play around with various strategies.

It's not trivial though and will probably take some time for us to come up with a solution that feels ergonomic.

We do have the cdk-dasm tool that you may find useful, though it generates code using L1s and has a bunch of other constraints that aren't ideal.

You can also try using CfnInclude to avoid having to "convert" existing templates and you can instead build on top of them, though this obviously has downsides as well.

Gonna close this for now since this is a known issue and requires a lot of research/design before the underlying solution can be implemented.