Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maintenance: Parser inferred result always set event to array type #3226

Closed
1 of 2 tasks
dreamorosi opened this issue Oct 22, 2024 · 3 comments · Fixed by #3293
Closed
1 of 2 tasks

Maintenance: Parser inferred result always set event to array type #3226

dreamorosi opened this issue Oct 22, 2024 · 3 comments · Fixed by #3293
Assignees
Labels
completed This item is complete and has been merged/shipped internal PRs that introduce changes in governance, tech debt and chores (linting setup, baseline, etc.) parser This item relates to the Parser Utility

Comments

@dreamorosi
Copy link
Contributor

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 }));

Image

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 }));

Image

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

Future readers

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

@dreamorosi dreamorosi added confirmed The scope is clear, ready for implementation internal PRs that introduce changes in governance, tech debt and chores (linting setup, baseline, etc.) parser This item relates to the Parser Utility labels Oct 22, 2024
@dreamorosi dreamorosi moved this from Triage to Backlog in Powertools for AWS Lambda (TypeScript) Oct 22, 2024
@am29d am29d self-assigned this Oct 29, 2024
@am29d am29d moved this from Backlog to Working on it in Powertools for AWS Lambda (TypeScript) Oct 29, 2024
@am29d
Copy link
Contributor

am29d commented Oct 29, 2024

This is strange. While WebStorm shows me non array inferred type for both EventBridgeEnvelope and SqsEnvelope, VSCode shows an array of the custom schema also for both envelopes. I have also tested Zed, it has the same behaviour as VSCode (but faster 😄 ).

Seems like WebStorm is inferring the wrong type

Just reindexed everything and WebStorm now shows correct type inference.

Copy link
Contributor

github-actions bot commented Nov 7, 2024

⚠️ 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 github-actions bot added pending-release This item has been merged and will be released soon and removed confirmed The scope is clear, ready for implementation labels Nov 7, 2024
Copy link
Contributor

This is now released under v2.11.0 version!

@github-actions github-actions bot added completed This item is complete and has been merged/shipped and removed pending-release This item has been merged and will be released soon labels Nov 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
completed This item is complete and has been merged/shipped internal PRs that introduce changes in governance, tech debt and chores (linting setup, baseline, etc.) parser This item relates to the Parser Utility
Projects
Status: Coming soon
Development

Successfully merging a pull request may close this issue.

2 participants