Closed
Description
Summary
When using the Middy.js middleware for parser, customers can specify envelopes and schemas for the middleware to use to parse the event. To ease usage for customers, we introduced types that are supposed to infer the event
type based on the arguments passed to the middleware.
Currently when using envelopes, the type of the event
is always assumed to be an array when it should not be the case.
For example, this is correct:
import middy from '@middy/core';
import { parser } from '@aws-lambda-powertools/parser/middleware';
import { SqsEnvelope } from '@aws-lambda-powertools/parser/envelopes';
import { z } from 'zod';
export const handler = middy(async () => {
return {
statusCode: 200,
body: JSON.stringify('Hello, World!'),
};
}).use(parser({ schema: z.any(), envelope: SqsEnvelope }));
but this is not:
import middy from '@middy/core';
import { parser } from '@aws-lambda-powertools/parser/middleware';
import { EventBridgeEnvelope } from '@aws-lambda-powertools/parser/envelopes';
import { z } from 'zod';
export const handler = middy(async () => {
return {
statusCode: 200,
body: JSON.stringify('Hello, World!'),
};
}).use(parser({ schema: z.any(), envelope: EventBridgeEnvelope }));
In the second case, EventBridge's detail-type
field is an object and not an array, but the types here think it's always an array.
Why is this needed?
So that the types when using the Middy.js middleware are correct.
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.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
Shipped