Bug: Parser's S3 event notifications schemas

[dreamorosi]

Summary

Based on the finding in aws-powertools/powertools-lambda-python#4156 it appears that when S3 sends a notification for an object deleted and triggers a Lambda function, the etag field is optional.

In looking at our implementation vs the types in @types/aws-lambda it seems that we have a single S3EventNotificationEventBridgeDetailSchema schema while DefinitelyTyped has multiple kinds, one for each notification type.

I'm not sure if we should add schemas for each event type like DefinitelyTyped does or have a single one, however having multiple might help with addressing the subtle differences in field presence (i.e. etag not present in delete notifications) & values (i.e. deletion-type equals Permanently Deleted).

For now I'm opening this as a feature request, but if we decide to just make etag optional and keep the schema as-is, we can convert this as maintenance type.

Why is this needed?

So that customers can use the schema to parse their events.

Which area does this relate to?

Parser

Solution

No response

Acknowledgment

• This request meets Powertools for AWS Lambda (TypeScript) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET

Future readers

Please react with 👍 and your use case to help us understand customer demand.

[am29d]

Hmm that's odd because the @types/aws-lambda has a required field etag on the notification event payload.

It would help to separate them and also narrow down the some of the field values to constants. Let me run some test events to see, I am a bit uncertain why the it happens "sometime" as stated in the original issue in PT python.

[dreamorosi]

Agree, the sometime is throwing me off as well.

It would make more sense to me that the field is no longer there because the corresponding object has been removed, but the intermittent aspect is strange.

[am29d]

I have decided to set the eTag to optional for now. The @types/aws-lambda are not correct thus we can't rely on them. In addition, splitting the event types would introduce redundancy between the events for common fields, or additional complexity if we decide to split them based on base and specific fields. It'd be hard to read them.

I need to think of possible scenarios how we could reproduce real event structures, because there is no other way yet to get them correct.

[github-actions]

⚠️ COMMENT VISIBILITY WARNING ⚠️

This issue is now closed. Please be mindful that future comments are hard for our team to see.

If you need more assistance, please either tag a team member or open a new issue that references this one.

If you wish to keep having a conversation with other community members under this issue feel free to do so.

[github-actions]

This is now released under v2.1.1 version!