Hello. I’m working on a serverless project my organization started months ago with a different developers working on it. It looks like they had manually provisioned a lot of the resources themselves instead of defining them in serverless.yml. In some cases, such as the rds instance, they had to. This makes it a little hard to debug, however.
sls deploy -v with SLS_DEBUG=* enabled is producing the following error:
ServerlessError: An error occurred: ProcessChangeEventSourceMappingSQSDatadistributordemo - The resource you requested does not exist. (Service: Lambda, Status Code: 404, Request ID: a4ab1842-0f1e-4175-905a-e75af2fbb84a, Extended Request ID: null).
I am not sure what could be causing this. When I check the CloudFormation stack, the EventSourceMapping is definitely there. It’s also there in the Lambda. How would I go about correcting this? Please let me know if you need to see anything else.
For anyone who might care about this issue, it self-resolved somehow the following day. Today, it is again occurring. I am not sure why. I think that my only choice at this point is to sls remove and redeploy. I would still love someone to provide some insight into this issue.
Had a similar issue, where one of my lambda functions had an SQS trigger initially deployed through “sls deploy”
Recently i had to change the batchSize of the SQS trigger for which i coulnd’t find an edit option. This time i manually deleted the existing SQS trigger and created a new one with the desired batchSize (wouldn’t have gotten into this issue if i had gone through the proper route of sls deploy).
Turns out, the initial resource that got created in the cloudformation stack for the SQS trigger, did not get deleted and was still holding the physical UUID of the old SQS trigger that i had deleted manually. So, now when i tried to deploy again it started throwing this “resource does not exist” error. This is due to the fact that the UUID of the new SQS trigger does not match with the physical UUID present in the resource mapping of cloudfromation stack.
In order to fix this,
I deleted the resource mapping that was referring to the old SQS trigger from the cloudformation stack template and updated it.
Also, i had to delete the new SQS trigger as well, or else it kept giving me “sqs trigger already exists error”. (I made the batchSize config changes in the serverless.yml instead)
And after that when i did the sls deploy, the resource got autocreated in the cloudformation stack and it started working.