Previously there was a bug with the teardown script where it would fail if an EMR Serverless Application was not in the correct state. This is still the case if scripts/test/maven/tearDown.sh is used.
Steps to reproduce
Run the quick system tests "scripts/test/maven/buildDeployTest.sh" "$SHORT_ID" "$VPC" "$SUBNETS"
After the tests have finished run scripts/test/maven/tearDown.sh "$SHORT_ID"-main
Teardown fails
Check the Cloud Formation logs for BulkImportEMRServerlessNestedStack
See error
Expected behaviour
Any EMR Serverless Applications deployed are stopped and destroyed as part of the teardown script. It should act the same as the other teardown scripts.
Screenshots/Logs
Resource handler returned message: "Invalid request provided: Application 987 must be in of the following statuses [CREATED, STOPPED]. Current status: STARTED (Service: EmrServerless, Status Code: 400, Request ID: 123)" (RequestToken: 456, HandlerErrorCode: InvalidRequest)
Background
The class TerminateEMRServerlessApplications already handles stoping an EMR Serverless application and is already used via TearDownInstance. The offending class is TearDownMavenSystemTest I think it might have something to do with the clients that are used.
Description
Previously there was a bug with the teardown script where it would fail if an EMR Serverless Application was not in the correct state. This is still the case if scripts/test/maven/tearDown.sh is used.
Steps to reproduce
Expected behaviour
Any EMR Serverless Applications deployed are stopped and destroyed as part of the teardown script. It should act the same as the other teardown scripts.
Screenshots/Logs
Resource handler returned message: "Invalid request provided: Application 987 must be in of the following statuses [CREATED, STOPPED]. Current status: STARTED (Service: EmrServerless, Status Code: 400, Request ID: 123)" (RequestToken: 456, HandlerErrorCode: InvalidRequest)
Background
The class TerminateEMRServerlessApplications already handles stoping an EMR Serverless application and is already used via TearDownInstance. The offending class is TearDownMavenSystemTest I think it might have something to do with the clients that are used.