Bug: parser built-in schema accept empty Records array

[Jimmy89]

Expected Behavior

Trying out the S3Schema parser with an empty records array passes validation. This should not occur.

Current Behavior

Output of success is true, while false was expected.

Code snippet

import { S3Schema } from '@aws-lambda-powertools/parser/schemas';
const event = { Records: [] };
const parsedEvent = await S3Schema.safeParseAsync(event);
console.log(parsedEvent.success); // <-- Output: true, expected: false  

Steps to Reproduce

Run code snippet above

Possible Solution

No response

Powertools for AWS Lambda (TypeScript) version

"@aws-lambda-powertools/parser": "2.13.0"

AWS Lambda function runtime

22.x

Packaging format used

npm

Execution logs

Zod version: 3.24.1

[dreamorosi]

Hi @Jimmy89, thank you for opening this issue.

I can confirm that if Records is an empty array validation passes. While in practice this can never happen in Lambda, since no record means no event, and thus no invocation, I think we should fix the schema and set a minimum of one item.

[Jimmy89]

Thank you @dreamorosi for putting it in the current iteration.
I'm wondering (not tested) if other schema parsers might have the same issue. I agree that in practice this should not occur that fast. However, in our case, we invoke the lambda with multiple different input types. I found this issue by doing a simple test, checking if our if statements would detect it as non-s3 event.

[dreamorosi]

Yes, I haven't checked all of them, but from spot checking a couple of them, all the built-in schemas we have that use z.array(something) would pass if the array is empty - which is a problem.

If you agree I'd like to modify the title of the issue to reflect this, so we can get them all fixed.

[Jimmy89]

@dreamorosi go ahead and adjust the title/content

[leandrodamascena]

Just my 2 cents here... I agree that events that any service sends to Lambda have at least one record. Some of them (S3, Kinesis, SQS, SNS and others) are a group of records - a list - and TS Parser should not accept an empty list.

In theory, empty events will never happen in the real world (Services -> Lambda), but based on what you're trying to achieve, @Jimmy89 , and to improve the developer experience/feedback loop, yes, we need to validate this in our models.

[dreamorosi]

I have started working on making changes to some of the schemas to address this bug.

• CloudWatch Log Events fix(parser): CloudWatch Log Envelope handles non-JSON #3505
• SNS fix(parser): SNS Envelope handles non-JSON #3506
• DynamoDB fix(parser): DynamoDBStream schema & envelope #3482
• Kafka fix(parser): Kafka Envelope + tests #3489

I'll continue adding the .min(1) constraint where it makes sense over the next few PRs that I am planning on working on.

[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.

[dreamorosi]

Reopening as there're still a few schemas to fix in #3521

[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.13.1 version!