fix: race condition provisioning default apigw responses #731
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
edwardfoyle
force-pushed
the
default-response-headers
branch
from
5831508
to
378551a
Compare
AaronZyLee
previously approved these changes
Aug 15, 2022
sundersc
previously approved these changes
Aug 15, 2022
edwardfoyle
force-pushed
the
default-response-headers
branch
from
378551a
to
c46ac89
Compare
phani-srikar
approved these changes
Aug 16, 2022
AaronZyLee
approved these changes
Aug 17, 2022
5 tasks
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.
Description of changes
Functional changes are in
_setDeploymentResource. All other changes were auto-fixed by the linter or me trying to make the linter happy while not bloating the PR too much.This change fixes the flakiness we have seen in
apigw.test.tswhere the default CORS headers are not included in 4xx and 5xx responses. This was caused because the REST API, default responses and REST API deployment are all separate CFN resources. The REST API deployment has an implicit dependency on the REST API, but the default responses must also be provisioned before the REST API deployment is provisioned. There was a race condition where sometimes the default responses would be provisioned in time and sometimes not. This PR adds an explicit dependency between the REST API deployment and the default response resourcesIssue #, if available
https://app.circleci.com/pipelines/github/aws-amplify/amplify-cli/10233/workflows/6d1d1682-c1d9-4265-b012-096c9db2e4c7/jobs/331564 (one of many flakes)
Description of how you validated changes
It's difficult to be 100% sure this fixes it because of the nature of intermittent failures, but I ran the test locally a few times and they all passed after this change
Checklist
yarn testpassesBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.