-
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
(apigatewayv2): AddRoutes caches lambda integrations incorrectly #13213
Comments
@ayush987goyal - can you take a look? |
Hi @ShadowDog007 , I am not able to reproduce the above issue with the below code: import * as cdk from '@aws-cdk/core';
import { HttpApi } from '@aws-cdk/aws-apigatewayv2';
import * as integrations from '@aws-cdk/aws-apigatewayv2-integrations';
import * as lambda from '@aws-cdk/aws-lambda';
export class ApiIntegStack extends cdk.Stack {
constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const lambda1 = new lambda.Function(this, 'AlwaysSuccess1', {
runtime: lambda.Runtime.NODEJS_12_X,
handler: 'index.handler',
code: new lambda.InlineCode(
'exports.handler = async function(event, context) { return { statusCode: 200, body: "success1" }; };'
),
});
const lambda2 = new lambda.Function(this, 'AlwaysSuccess2', {
runtime: lambda.Runtime.NODEJS_12_X,
handler: 'index.handler',
code: new lambda.InlineCode(
'exports.handler = async function(event, context) { return { statusCode: 200, body: "success2" }; };'
),
});
const httpApi = new HttpApi(this, 'LambdaProxyApi');
httpApi.addRoutes({
path: '/service1',
integration: new integrations.LambdaProxyIntegration({
handler: lambda1,
}),
});
httpApi.addRoutes({
path: '/service2',
integration: new integrations.LambdaProxyIntegration({
handler: lambda2,
}),
});
new cdk.CfnOutput(this, 'Endpoint', {
value: httpApi.url!,
});
}
} Testing:
Could you please check if you are using the latest version of AWS CDK and also try out the above code? It would help if you could provide more details on you implementation to dive deep further. |
Hey @ayush987goyal I did some testing and struggled for a bit to reproduce it in a brand new application. The specific reason why it was happening in my application was because the id of my Function was the same in two stacks. The id of my functions were both 'Function', but in different stacks
|
It's mainly driven by the |
Right, but the ARN is based off the function name, but I'm letting CloudFormation generate one (which bases it off the stack name and resource name). So the ARN's are different? (Just not known at synth time) |
Yeah ideally they should be different if they are in different stacks. I am not really sure what specific scenario you have in your local workspace. If you could provide a reproduction then we could further look into it. |
@ayush987goyal Created this: https://github.com/ShadowDog007/aws-cdk-apigatewayv2-integration-issue-reproduction Added the output here too, which shows only a single integration where there should be two. |
I have reproduced it locally and can confirm this is indeed a bug. We will look into the same. |
To confirm, this happens when the function name is the same but defined in different stacks. Is that right? |
Yes just confirmed that this only happens when the function name is same and defined in different stacks. |
…esource Routes on APIGateway V2 can integrate with different backends. This is achieved by creating the CFN resource `AWS::ApiGatewayV2::Integration` that is then referenced in the resource for the Route. Currently, the `IHttpRouteIntegration` (and `IWebSocketRouteIntegration`) interface represents a unique backend that a route can integrate with, using the CDK "bind" pattern. An integration can be bound to any number of routes but should be rendered into a single instance of `AWS::ApiGatewayV2::Integration` resource. To achieve this currently, the `HttpApi` (and `WebSocketApi`) class holds a cache of all integrations defined against its routes. This is the wrong level of caching and causes a number of problems. 1. We rely on the configuration of the `AWS::ApiGateway::Integration` resource to determine if one already exists. This means that two instances of `IHttpRouteIntegration` can result in rendering only one instance of `AWS::ApiGateway::Integration` resource. Users may want to intentionally generate multiple instances of `AWS::ApiGateway::Integration` classes with the same configuration. Taking away this power with CDK "magic" is just confusing. 2. Currently, we allow using the same instance of `IHttpRouteIntegration` (or `IWebSocketRouteIntegration`) to be bound to routes in different `HttpApi`. When bound to the route, the CDK renders an instance of `AWS::ApiGatewayV2::Integration` for each API. This is another "magic" that has the potential for user confusion and bugs. The solution is to KeepItSimple™. Remove the API level caching and simply cache at the level of each integration. This ensures that each instance of `HttpRouteIntegration` (previously `IHttpRouteIntegration`) renders to exactly one instance of `AWS::ApiGatewayV2::Integration`. Disallow using the same instance of `HttpRouteIntegration` across different instances of `HttpApi`. fixes #13213 BREAKING CHANGE: The interface `IHttpRouteIntegration` is replaced by the abstract class `HttpRouteIntegration`. * **apigatewayv2:** The interface `IWebSocketRouteIntegration` is now replaced by the abstract class `WebSocketRouteIntegration`. * **apigatewayv2:** Previously, we allowed the usage of integration classes to be used with routes defined in multiple `HttpApi` instances (or `WebSocketApi` instances). This is now disallowed, and separate instances must be created for each instance of `HttpApi` or `WebSocketApi`.
…esource (#17729) Routes on APIGateway V2 can integrate with different backends. This is achieved by creating the CFN resource `AWS::ApiGatewayV2::Integration` that is then referenced in the resource for the Route. Currently, the `IHttpRouteIntegration` (and `IWebSocketRouteIntegration`) interface represents a unique backend that a route can integrate with, using the CDK "bind" pattern. An integration can be bound to any number of routes but should be rendered into a single instance of `AWS::ApiGatewayV2::Integration` resource. To achieve this currently, the `HttpApi` (and `WebSocketApi`) class holds a cache of all integrations defined against its routes. This is the wrong level of caching and causes a number of problems. 1. We rely on the configuration of the `AWS::ApiGateway::Integration` resource to determine if one already exists. This means that two instances of `IHttpRouteIntegration` can result in rendering only one instance of `AWS::ApiGateway::Integration` resource. Users may want to intentionally generate multiple instances of `AWS::ApiGateway::Integration` classes with the same configuration. Taking away this power with CDK "magic" is just confusing. 2. Currently, we allow using the same instance of `IHttpRouteIntegration` (or `IWebSocketRouteIntegration`) to be bound to routes in different `HttpApi`. When bound to the route, the CDK renders an instance of `AWS::ApiGatewayV2::Integration` for each API. This is another "magic" that has the potential for user confusion and bugs. The solution is to KeepItSimple™. Remove the API level caching and simply cache at the level of each integration. This ensures that each instance of `HttpRouteIntegration` (previously `IHttpRouteIntegration`) renders to exactly one instance of `AWS::ApiGatewayV2::Integration`. Disallow using the same instance of `HttpRouteIntegration` across different instances of `HttpApi`. fixes #13213 BREAKING CHANGE: The interface `IHttpRouteIntegration` is replaced by the abstract class `HttpRouteIntegration`. * **apigatewayv2:** The interface `IWebSocketRouteIntegration` is now replaced by the abstract class `WebSocketRouteIntegration`. * **apigatewayv2:** Previously, we allowed the usage of integration classes to be used with routes defined in multiple `HttpApi` instances (or `WebSocketApi` instances). This is now disallowed, and separate instances must be created for each instance of `HttpApi` or `WebSocketApi`. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
…esource (aws#17729) Routes on APIGateway V2 can integrate with different backends. This is achieved by creating the CFN resource `AWS::ApiGatewayV2::Integration` that is then referenced in the resource for the Route. Currently, the `IHttpRouteIntegration` (and `IWebSocketRouteIntegration`) interface represents a unique backend that a route can integrate with, using the CDK "bind" pattern. An integration can be bound to any number of routes but should be rendered into a single instance of `AWS::ApiGatewayV2::Integration` resource. To achieve this currently, the `HttpApi` (and `WebSocketApi`) class holds a cache of all integrations defined against its routes. This is the wrong level of caching and causes a number of problems. 1. We rely on the configuration of the `AWS::ApiGateway::Integration` resource to determine if one already exists. This means that two instances of `IHttpRouteIntegration` can result in rendering only one instance of `AWS::ApiGateway::Integration` resource. Users may want to intentionally generate multiple instances of `AWS::ApiGateway::Integration` classes with the same configuration. Taking away this power with CDK "magic" is just confusing. 2. Currently, we allow using the same instance of `IHttpRouteIntegration` (or `IWebSocketRouteIntegration`) to be bound to routes in different `HttpApi`. When bound to the route, the CDK renders an instance of `AWS::ApiGatewayV2::Integration` for each API. This is another "magic" that has the potential for user confusion and bugs. The solution is to KeepItSimple™. Remove the API level caching and simply cache at the level of each integration. This ensures that each instance of `HttpRouteIntegration` (previously `IHttpRouteIntegration`) renders to exactly one instance of `AWS::ApiGatewayV2::Integration`. Disallow using the same instance of `HttpRouteIntegration` across different instances of `HttpApi`. fixes aws#13213 BREAKING CHANGE: The interface `IHttpRouteIntegration` is replaced by the abstract class `HttpRouteIntegration`. * **apigatewayv2:** The interface `IWebSocketRouteIntegration` is now replaced by the abstract class `WebSocketRouteIntegration`. * **apigatewayv2:** Previously, we allowed the usage of integration classes to be used with routes defined in multiple `HttpApi` instances (or `WebSocketApi` instances). This is now disallowed, and separate instances must be created for each instance of `HttpApi` or `WebSocketApi`. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…esource (aws#17729) Routes on APIGateway V2 can integrate with different backends. This is achieved by creating the CFN resource `AWS::ApiGatewayV2::Integration` that is then referenced in the resource for the Route. Currently, the `IHttpRouteIntegration` (and `IWebSocketRouteIntegration`) interface represents a unique backend that a route can integrate with, using the CDK "bind" pattern. An integration can be bound to any number of routes but should be rendered into a single instance of `AWS::ApiGatewayV2::Integration` resource. To achieve this currently, the `HttpApi` (and `WebSocketApi`) class holds a cache of all integrations defined against its routes. This is the wrong level of caching and causes a number of problems. 1. We rely on the configuration of the `AWS::ApiGateway::Integration` resource to determine if one already exists. This means that two instances of `IHttpRouteIntegration` can result in rendering only one instance of `AWS::ApiGateway::Integration` resource. Users may want to intentionally generate multiple instances of `AWS::ApiGateway::Integration` classes with the same configuration. Taking away this power with CDK "magic" is just confusing. 2. Currently, we allow using the same instance of `IHttpRouteIntegration` (or `IWebSocketRouteIntegration`) to be bound to routes in different `HttpApi`. When bound to the route, the CDK renders an instance of `AWS::ApiGatewayV2::Integration` for each API. This is another "magic" that has the potential for user confusion and bugs. The solution is to KeepItSimple™. Remove the API level caching and simply cache at the level of each integration. This ensures that each instance of `HttpRouteIntegration` (previously `IHttpRouteIntegration`) renders to exactly one instance of `AWS::ApiGatewayV2::Integration`. Disallow using the same instance of `HttpRouteIntegration` across different instances of `HttpApi`. fixes aws#13213 BREAKING CHANGE: The interface `IHttpRouteIntegration` is replaced by the abstract class `HttpRouteIntegration`. * **apigatewayv2:** The interface `IWebSocketRouteIntegration` is now replaced by the abstract class `WebSocketRouteIntegration`. * **apigatewayv2:** Previously, we allowed the usage of integration classes to be used with routes defined in multiple `HttpApi` instances (or `WebSocketApi` instances). This is now disallowed, and separate instances must be created for each instance of `HttpApi` or `WebSocketApi`. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…esource (aws#17729) Routes on APIGateway V2 can integrate with different backends. This is achieved by creating the CFN resource `AWS::ApiGatewayV2::Integration` that is then referenced in the resource for the Route. Currently, the `IHttpRouteIntegration` (and `IWebSocketRouteIntegration`) interface represents a unique backend that a route can integrate with, using the CDK "bind" pattern. An integration can be bound to any number of routes but should be rendered into a single instance of `AWS::ApiGatewayV2::Integration` resource. To achieve this currently, the `HttpApi` (and `WebSocketApi`) class holds a cache of all integrations defined against its routes. This is the wrong level of caching and causes a number of problems. 1. We rely on the configuration of the `AWS::ApiGateway::Integration` resource to determine if one already exists. This means that two instances of `IHttpRouteIntegration` can result in rendering only one instance of `AWS::ApiGateway::Integration` resource. Users may want to intentionally generate multiple instances of `AWS::ApiGateway::Integration` classes with the same configuration. Taking away this power with CDK "magic" is just confusing. 2. Currently, we allow using the same instance of `IHttpRouteIntegration` (or `IWebSocketRouteIntegration`) to be bound to routes in different `HttpApi`. When bound to the route, the CDK renders an instance of `AWS::ApiGatewayV2::Integration` for each API. This is another "magic" that has the potential for user confusion and bugs. The solution is to KeepItSimple™. Remove the API level caching and simply cache at the level of each integration. This ensures that each instance of `HttpRouteIntegration` (previously `IHttpRouteIntegration`) renders to exactly one instance of `AWS::ApiGatewayV2::Integration`. Disallow using the same instance of `HttpRouteIntegration` across different instances of `HttpApi`. fixes aws#13213 BREAKING CHANGE: The interface `IHttpRouteIntegration` is replaced by the abstract class `HttpRouteIntegration`. * **apigatewayv2:** The interface `IWebSocketRouteIntegration` is now replaced by the abstract class `WebSocketRouteIntegration`. * **apigatewayv2:** Previously, we allowed the usage of integration classes to be used with routes defined in multiple `HttpApi` instances (or `WebSocketApi` instances). This is now disallowed, and separate instances must be created for each instance of `HttpApi` or `WebSocketApi`. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
When adding multiple routes with lambda integrations on a single http api, all routes end up sharing the same integration, instead of being correctly bound to the lambda which was provided.
Reproduction Steps
What did you expect to happen?
Two routes with their own integrations created
What actually happened?
Correct routes/lambda permissions, but both routes share the same lambda integration (the first one which was added)
Environment
Other
It appears that the Lambda arn doesn't become part of the cache key?
https://github.com/aws/aws-cdk/blob/v1.90.1/packages/@aws-cdk/aws-apigatewayv2/lib/http/api.ts#L281
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: