Lambda's loop detection after it became compatible with loops triggered by S3.

Regarding the

During the 2023 update, I wrote verification articles in the following post.

For the runtime of the verification Lambda, I am using the one I created last time.

The result is... it stops properly (well, it has to stop, right? lol)

Before the update, it looked like this. ※From the previous verification.

Notifications are also displayed on the AWS Health Dashboard as usual.

Additional Verification Needed

In this loop case, there is no flow to trigger a notification, so I think it might be possible to notify by setting a DLQ for Lambda.

I will try a slightly modified version of the flow. Also, I will additionally verify what happens when S3 and SQS are combined and update the article.

What Not to Forget (I Write This Every Time)

Although the long-awaited implementation for S3 triggers has been made, as I mentioned in a previous article, even though it has been implemented, we should not rely on it.

To begin with,

we should avoid loops.

I will not forget this. With S3 support, I think all cases that might cause an infinite loop have been addressed, but I still believe that avoiding loops in the first place is the most important.

In Case of Intentional Looping...

In cases where looping is intentional, stopping at 16 times becomes a problem, so in such cases,it seems that it can be disabled using the PutFunctionRecursionConfig API.

(I think it used to be raising a support case...) I might try it later...

The End

Detection & stopping is just a guardrail, I think (it's also mentioned in the guide).

As mentioned above, unless it's intentional,

it's important to avoid loops in the first place, and I will be careful not to do so.

This article is being translated from Japanese to English using Amazon Bedrock and Amazon Nova Pro.

Additionally, the title image is being generated using Amazon Bedrock and Amazon Nova Canvas.