Bolt v4 addendum: stricter typing of AWS API Gateway payloads #2277
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
filmaj
added
enhancement
filmaj
changed the title
seratch
approved these changes
Oct 2, 2024
|
Once the lint error is resolved and the main branch is ready for v4 changes, we can merge this PR |
|
The lint and test errors will be resolved by #2259; I will merge this into the v4 PR in the mean time. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR is an addendum / expansion on a proposed change in bolt v4: better typing of the AWS payload interfaces. This is applicable to consumers using the
AwsLambdaReceiver. This PR would fix #2272.Background
In my initial bolt-v4 PR, @seratch observed that some of the typing adjustments I was making to AWS payloads was simplistic and could be enhanced. He also pointed me to #2272 as a potential issue that could be resolved by doing a bit more work in properly typing both V1 and V2 AWS API Gateway payloads.
This PR attempts to improve these AWS payload types to support both V1 and V2 APIG payloads. A side benefit is it requires bolt code to be a bit more strict and correct when retrieving the URL path from this payload (by requiring to account for the difference in what the relevant property for this is in V1 vs. V2).
If approved, these changes, and how to migrate from bolt v3 to v4 app code to take into account these interface changes - particularly for apps setting
customPropertiesExtractororinvalidSignatureHandlermethods - would need to be documented in a bolt v3 -> v4 migration guide.