What is s3:TestEvent, and why does it break my event processing?

This article is a part of my "100 data engineering tutorials in 100 days" challenge. (68/100)

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:

1
2
3
4
5
6
7
8
{
    "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.

Subscribe to the newsletter and join the free email course.


Remember to share on social media!
If you like this text, please share it on Facebook/Twitter/LinkedIn/Reddit or other social media.

If you want to contact me, send me a message on LinkedIn or Twitter.

Would you like to have a call and talk? Please schedule a meeting using this link.


Bartosz Mikulski
Bartosz Mikulski * MLOps Engineer / data engineer * conference speaker * co-founder of Software Craft Poznan & Poznan Scala User Group

Subscribe to the newsletter and get access to my free email course on building trustworthy data pipelines.