When you setup SQS notifications in an S3 bucket, for example, when you want to get a message when a new file is uploaded into the bucket, the first thing you get is an s3:TestEvent which looks like this:
{
"Service":"Amazon S3",
"Event":"s3:TestEvent",
"Time":"2020-11-30T00:00:00.000Z",
"Bucket":"the_bucket_name",
"RequestId":"some_id",
"HostId":"another_id"
}
Its structure differs from all of the other notifications sent by S3, so most likely, it will break your event processing code. Don’t worry. AWS will send that only once to test whether S3 can publish messages to your SQS queue.
Unfortunately, they will not automatically remove that message after the test. There are three ways to deal with that problem:
- wait until the message expires - unprofessional, but totally valid solution
- setup a dead letter queue - most likely, you will have another function that processes the messages in DLQ, and it may fail too
- poll messages from the queue, locate the
s3:TestEvent, and remove it - probably the best option, unless you plan to change the configuration of S3 notifications multiple times a day and keep getting new test events.
Want to build AI systems that actually work?
Download my expert-crafted GenAI Transformation Guide for Data Teams and discover how to properly measure AI performance, set up guardrails, and continuously improve your AI solutions like the pros.