-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
fix: options endpoint does not invoke lambda (fixing CI issues with author's PR) (#1434) #1649
Conversation
I am pulling this PR and the original PR down locally to resubmit as one. |
@douglasnaphas I would start by looking at the failing integration tests. |
@sanathkr Did you have any luck resubmitting this along with the original PR? |
aws#1434 This is intended to get the following integration tests passing: tests/integration/local/start_api/test_start_api.py TestServiceCorsSwaggerRequests TestServiceCorsGlobalRequests Those tests use a [CorsConfiguration](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-api-corsconfiguration.html) and a [Cors Global](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-template-anatomy-globals.html), respectively, to enable CORS. When CORS is enabled, OPTIONS requests should send a 200 with the specified CORS headers, even if no OPTIONS handler is explicitly stated in the pre-transformation SAM template. I confirmed this by deploying from a [SAM template](https://github.com/douglasnaphas/play-sam/tree/master/cors-swagger) similar to one of the failing integration tests (with Cors specified but with no explicit OPTIONS handler), and observing that it does indeed respond with a 200 and the CORS headers attached.
85ff184
to
0835fa6
Compare
aws#1434 This adds an integration test to verify that templates with explicit OPTIONS handlers actually have those handlers invoked on OPTIONS requests. There has been an issue with OPTIONS requests returning 200 and not reaching an explicitly specified OPTIONS handler. aws#1649 fixes that, so if the integration test added in this commit passes (and fails on the develop branch), it could be added to that PR.
aws#1434 This adds an integration test to verify that templates with explicit OPTIONS handlers actually have those handlers invoked on OPTIONS requests. There has been an issue with OPTIONS requests returning 200 and not reaching an explicitly specified OPTIONS handler. aws#1649 fixes that, so if the integration test added in this commit passes (and fails on the develop branch), it could be added to that PR.
The integration test added in this PR passes when run locally with When I apply the integration test, but not the code change, to the
|
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.
LGTM! Thanks for keeping up with this and spending the time to address the bug.
`black --diff tests/integration/local/start_api/test_start_api.py` reported this issue--a missing newline between classes.
Issue #, if available: #1434
Description of changes: This attempts to fix the CI failures encountered with @gordonmleigh's PR #1464.
Checklist:
make pr
passesBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.