-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
APIGW NG add Integration Response selection and parameter mapping #11135
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
Conversation
LocalStack Community integration with Pro 2 files ± 0 2 suites ±0 23m 31s ⏱️ - 1h 16m 14s Results for commit b8e979d. ± Comparison against base commit 6ea7da3. This pull request removes 2513 tests.
♻️ This comment has been updated with latest results. |
5b79f77
to
d4e624d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀 Awesome PR. Nice structure to the handler.
I still have some doubt/questions around the AWS
lambda integration and the differences in how it handles success/error, but I guess we will discover more as we complete it's handler. For now, it seems logic to proceed this way, as the error end up in the body for the mapping, so we need it here.
Really good and clear tests. Congrats!
|
||
return response_data_mapping | ||
|
||
def _retrieve_parameter_from_variables_and_static( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! That will be ready for reuse in the gateway responses as well when we get there!
try: | ||
decoded_body = self._json_load(body) | ||
except ValueError: | ||
# x-amzn-errortype: InternalFailureException |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🙏
|
||
# this was validated against AWS | ||
assert mapping == { | ||
"header": {"body_value": "{}"}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's back 👻
@cloutierMat yes, it's a bit specific, but it seems it's well documented in the documentation, and it seems it really happens at the Integration Response level, as they talk about the fact that the Integration will always return |
# override them if there are overrides. | ||
# for the body, it will maybe depend on configuration? | ||
|
||
response.headers.clear() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cloutierMat this might have been a bit too aggressive 😄 I think we might need to keep a few, HTTP related headers, like Content-Type
, Content-Length
, etc. Might need to keep a list, and selectively remove all other headers. We can quickly try it with an integration with no mappings I suppose!
Motivation
This PR starts implementing the Integration Response handler, who's responsible for selecting the right
IntegrationResponse
based on the response status code (or anerrorMessage
field very specific to theAWS
integration with Lambda, which we will tackle later).The handler should then do the response parameters mapping, then the VTL rendering of the body.
We do not test the handler yet, same as the Integration Request handler, as the behavior is incomplete yet.
Instead, we can focus on the integration response selection, and the response parameters mapping. All of the unit tests have been manually tested against AWS, with the console and a SSH tunnel with localhost.run to my own small flask server to be able to return arbitrary payload from my HTTP payload.
More informations about the different subjects of the PR:
Changes
selectionPattern
util to select the right integration response (thanks @dfangl for implementing it!) and unit test itTODO
What's left to do: