chore(stepfunctions): add waitForAssertions to distributed-map assertions to wait for the expected resource state
#30286
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
Signed-off-by: Francis <colifran@amazon.com>
colifran
changed the title
waitForAssertion to assertions to wait the expected responsewaitForAssertion to assertions to wait for the expected response
colifran
changed the title
waitForAssertion to assertions to wait for the expected responsewaitForAssertion to distributed-map assertions to wait for the expected response
aws-cdk-automation
added
the
pr/needs-maintainer-review
colifran
changed the title
waitForAssertion to distributed-map assertions to wait for the expected responsewaitForAssertion to distributed-map assertions to wait for the expected resource state
colifran
changed the title
waitForAssertion to distributed-map assertions to wait for the expected resource statewaitForAssertions to distributed-map assertions to wait for the expected resource state
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
aws-cdk-automation
removed
the
pr/needs-maintainer-review
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
mazyu36
pushed a commit
to mazyu36/aws-cdk
that referenced
this pull request
May 22, 2024
…rtions to wait for the expected resource state (aws#30286) ### Reason for this change Two assertions made in `integ.distributed-map.ts` are waiting on a specific resource state. The following waits for a state machine to be `ACTIVE`: ```ts testCase.assertions .awsApiCall('StepFunctions', 'describeStateMachine', { stateMachineArn: stack.stateMachine.stateMachineArn, }) .expect(ExpectedResult.objectLike({ status: 'ACTIVE' })); ``` The following wait for the state machine execution to be `SUCCEEDED`: ```ts describe.expect(ExpectedResult.objectLike({ status: 'SUCCEEDED', })); ``` In the current format, the second assertion fails because the state machine execution is still running at the time the assertion is made. This causes the integ test to fail with the following error: ``` { "executionArn": "arn:aws:states:us-east-1:123456789012:execution:StateMachine2E01A3A5-OqZg4PaGWIUA:ecfc64d5-c20e-483b-a2ec-9ef8f82b2214", "input": "{}", "inputDetails": { ... }, "name": "ecfc64d5-c20e-483b-a2ec-9ef8f82b2214", "redriveCount": 0, "redriveStatus": "NOT_REDRIVABLE", "redriveStatusReason": "Execution is RUNNING and cannot be redriven", "startDate": {}, "stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:StateMachine2E01A3A5-OqZg4PaGWIUA", !! Expected SUCCEEDED but received RUNNING "status": "RUNNING", "traceHeader": "Root=1-664c0401-4504db7463bcd92c490e52bc;Parent=5ea37aeb46708a96;Sampled=0" } ``` As a best practice, we should always ensure that assertions based on resource state have a `waitForAssertions` call to force the assertion to wait for the specific state to occur. ### Description of changes I added a `waitForAssertions` call to each assertion in this integ test that is waiting for a specific resource state. Each `waitForAssertions` call has the following waiter options: - A total timeout of 5 minutes, after which the assertion will fail. - A 10 second interval which will be used to check if the resource is in the expected state. ### Description of how you validated changes Re-ran the integ test and it succeeded. ### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This was referenced May 27, 2024
atanaspam
pushed a commit
to atanaspam/aws-cdk
that referenced
this pull request
Jun 3, 2024
…rtions to wait for the expected resource state (aws#30286) ### Reason for this change Two assertions made in `integ.distributed-map.ts` are waiting on a specific resource state. The following waits for a state machine to be `ACTIVE`: ```ts testCase.assertions .awsApiCall('StepFunctions', 'describeStateMachine', { stateMachineArn: stack.stateMachine.stateMachineArn, }) .expect(ExpectedResult.objectLike({ status: 'ACTIVE' })); ``` The following wait for the state machine execution to be `SUCCEEDED`: ```ts describe.expect(ExpectedResult.objectLike({ status: 'SUCCEEDED', })); ``` In the current format, the second assertion fails because the state machine execution is still running at the time the assertion is made. This causes the integ test to fail with the following error: ``` { "executionArn": "arn:aws:states:us-east-1:123456789012:execution:StateMachine2E01A3A5-OqZg4PaGWIUA:ecfc64d5-c20e-483b-a2ec-9ef8f82b2214", "input": "{}", "inputDetails": { ... }, "name": "ecfc64d5-c20e-483b-a2ec-9ef8f82b2214", "redriveCount": 0, "redriveStatus": "NOT_REDRIVABLE", "redriveStatusReason": "Execution is RUNNING and cannot be redriven", "startDate": {}, "stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:StateMachine2E01A3A5-OqZg4PaGWIUA", !! Expected SUCCEEDED but received RUNNING "status": "RUNNING", "traceHeader": "Root=1-664c0401-4504db7463bcd92c490e52bc;Parent=5ea37aeb46708a96;Sampled=0" } ``` As a best practice, we should always ensure that assertions based on resource state have a `waitForAssertions` call to force the assertion to wait for the specific state to occur. ### Description of changes I added a `waitForAssertions` call to each assertion in this integ test that is waiting for a specific resource state. Each `waitForAssertions` call has the following waiter options: - A total timeout of 5 minutes, after which the assertion will fail. - A 10 second interval which will be used to check if the resource is in the expected state. ### Description of how you validated changes Re-ran the integ test and it succeeded. ### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
Comments on closed issues and PRs are hard for our team to see. If you need help, please open a new issue that references this one. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Reason for this change
Two assertions made in
integ.distributed-map.tsare waiting on a specific resource state. The following waits for a state machine to beACTIVE:The following wait for the state machine execution to be
SUCCEEDED:In the current format, the second assertion fails because the state machine execution is still running at the time the assertion is made. This causes the integ test to fail with the following error:
As a best practice, we should always ensure that assertions based on resource state have a
waitForAssertionscall to force the assertion to wait for the specific state to occur.Description of changes
I added a
waitForAssertionscall to each assertion in this integ test that is waiting for a specific resource state. EachwaitForAssertionscall has the following waiter options:Description of how you validated changes
Re-ran the integ test and it succeeded.
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license