about Detect and stop Lambda loops Launching in 2023, October 2024, the long-awaited (I think) detection and stopping of loops using S3 triggers has been supported!
During the 2023 update, I wrote the verification article in the article below.
As a continuation, or rather since at that time S3 triggers were not the target of detection and stopping, and I wrote that I would be happy if they were updated in the future, I revalidated the S3 triggers after the update. (Two months late…sorry)
I will also update past articles later.
For the validation Lambda’s runtime, I’m using the one I created last time.
https://github.com/Kenichiro-Wada/aws-lambda-recursion-detection
It works as-is, but the following issues have been addressed:
- Updates to various modules,
- Node.js execution time version upgrade (v18 -> v22)
- Added 5 seconds wait in internal process (to prevent it from stopping immediately)
- Updated readme file (mentioning detection and stopping)
Verify loop detection and notification using S3 triggers
Detection verification is completed through the following configuration.
Just to confirm there was no problem, I also checked the other detection modes, but since there was no particular change in behavior I’ll ignore them.
If you are interested, you can refer to previous articles.
turn out… it stops normally (Well, it has to stop, right? Haha)
According to the metric, it was also executed 16 times.
Before the update, it looked like this. ※Based on previous verification.
Searching Cloudwatch Logs for the message output within the Lambda shows 16 entries, indicating that it is limited to 16 executions.
The indicator for detection and stopping is “recursive call drop” and one stop has been logged.
Notifications also appear on the AWS Health Dashboard as usual.
Requires additional verification
In this loop situation, there is no process that can trigger the notification, so I think it can be done by setting a DLQ for the Lambda.
I’m going to try a slightly modified version of this process. In addition, I will additionally verify what happens when S3 and SQS are combined and update the article.
Don’t forget anything (I write this every time)
Although the long-awaited S3 trigger implementation has been implemented, as I mentioned in my previous article, we should not rely on it even if it is implemented.
first,
We should avoid loops.
I won’t forget this. With S3 support, I think all situations that could lead to infinite loops are solved, but I still think it’s most important to avoid loops in the first place.
If you loop on purpose…
In the case of intentional looping, stopping at 16 times would be a problem, so in this case it seems possible to use PutFunctionRecursionConfig API.
(I think it once raised a support case…) I might try that later…
ending
In my opinion, detection and stopping are just a guardrail (also mentioned in the guide).
As stated above, unless it is intentional,
It’s important to avoid loops in the first place, I would be careful not to do this.
This article is being translated from Japanese to English using Amazon Bedrock and Amazon Nova Pro.
Additionally, the header image was generated using Amazon Bedrock and Amazon Nova Canvas.