-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
(integ-tests): Can't make two awsApiCall for the same service and api in a given context #22043
Comments
Thanks for the report @dontirun, We could either change how the logical id is built altogether (which would change the logical id for existing instances so we'd likely need a feature flag), or what's more preferable is to somehow detect if the same API call has already been used, and then adjusting the logical ID from there if that's the case. However I'm not sure how feasible the latter is without looking more into it |
While not generally advisable, I'm working around this right now by importing from import { AwsApiCall, IntegTest } from '@aws-cdk/integ-tests-alpha';
import { DeployAssert } from '@aws-cdk/integ-tests-alpha/lib/assertions/private/deploy-assert';
// ...
declare const integTest: IntegTest;
const deployAssert = integTest.assertions;
if (!DeployAssert.isDeployAssert(deployAssert)) {
throw new Error('Expected DeployAssert');
}
// Extract the assertion scope from the DeployAssert because upstream
// implementation fails to allow multiples of the same aws api call
// due to insufficient uniqueness in the logical ids.
const assertionScope = deployAssert.scope;
const assertion1 = new AwsApiCall(assertionScope, 'First', {
service: 'TheService',
api: 'theApi',
parameters: { /* ... */ },
});
const assertion2 = new AwsApiCall(assertionScope, 'Second', {
service: 'TheService',
api: 'theApi',
parameters: { /* ... */ },
}); Edit: I've proposed a backward-compatible PR, hoping to fix the issue at its root. You can find it below. |
This PR resolves errors in the integration test library when users run identical assertions multiple times. This change ensures that each use of `awsApiCall`, `httpApiCall`, and `invokeFunction` has a unique identifier, even when multiple identical assertions are used in the same context. We introduced a `uniqueAssertionId` function in the `DeployAssert` construct that maintains backward compatibility with the old id rendering scheme, but prevents the use of conflicting construct ids by tracking the usage of ids and differentiating them where there's a conflict. Closes #22043, #23049 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
Describe the bug
While fumbling around with integration tests I received the following error
Error: There is already a Construct with name 'AwsApiCallRedshiftdescribeClusters' in Stack [DeployAssert]
I believe this is because I had two calls for the same service and api
Expected Behavior
I can make two calls to the same service API combo
Current Behavior
I can't make two calls to the same service API combo
Reproduction Steps
Possible Solution
aws-cdk/packages/@aws-cdk/integ-tests/lib/assertions/private/deploy-assert.ts
Line 53 in 1f03e8c
Maybe something like this?
Additional Information/Context
No response
CDK CLI Version
2.41.0
Framework Version
No response
Node.js Version
v16.16.0
OS
OsX
Language
Typescript
Language Version
No response
Other information
No response
The text was updated successfully, but these errors were encountered: