- Newest
- Most votes
- Most comments
That is indeed weird.
Can you outline what your code is doing? E.g. are there relevant variables and functions initialized outside the handler function?
What do you do inside the handler function?
If you can play around and this doesn't happen in your production environment: can you strip everything from your code and basically only keep a console.log(event)? This would help exclude error factors and sources.
Without seeing your code it is difficult to help.
I'd suggest adding some counter parameter or unique id to the request body.
Then log the complete event input so you can see what is happening with it.
Thanks for the reply. I do log the event input, and for the duplicates, they are exactly the same. Between API calls, they are not, as expected. We do use a timestamp which acts (more or less) as a unique id as well.
The code takes elastic search document ids that are in an array of the event input and processes them into new documents in elastic search. There are lambda variables defined in the Configuration/Environment Variables section of the lambda function, which are used as 'environment variables' to the function itself. But those are just passwords/logging level settings/etc. There are no other functions initialized outside the lambda code itself, although the function does call internal functions/classes/etc. as the code isn't all in just one function. (lambda handler creates instances of classes and calls methods on those classes). It is written in python 3.7 and the .py files are in different folders/etc. If there aren't any errors, the code finishes by returning a json object of an array of response/msg strings that are created during the execution. During the run in question, there were no exceptions so the code ran to completion each time.
Could it be I have to 'return' some statusCode (like 200) on completion instead of just a json object with whatever? If that were the case, though, then I would expect the 'duplication' behavior to be consistent, and it isn't.
This behavior does happen for both the prod API stage and dev API stage. Both stages call the same lambda function, although the dev stage/alias uses the $LATEST version while the prod stage/alias uses a numbered release version.
I'll look into just logging the event line and basically doing nothing else.
Thanks again!
Great suggestion to strip everything and just keep a log event! When I did that, the problem went away.
What I found out was the lambda function wasn't being called multiple times. The custom logger I use to output to elastic and the standard output was not being closed in the code, and so when the lambda ran again, it used that logger plus the new logger of the current run, etc. and stacked the output until cloudwatch used a new log file. I added code to close the custom log handlers and the problem is gone.
Thanks, Eric! Very much appreciated.
I had similar issues with Lambda when I went serverless for the first time.
Anyhow, I'm glad I could help.
Relevant content
- Accepted Answerasked 5 months ago
- asked 6 months ago
AWS OFFICIALUpdated 2 years ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
