-
Notifications
You must be signed in to change notification settings - Fork 4k
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
APIGateway and Lambdas in separate stacks fails #3705
Comments
I am having the exact same issue. I put all lambda functions into an object export interface Function {
[name: string]: lambda.Function;
} and exposed it by public readonly functions: Function = {}; and add function to it in this.functions.testNpmModulesLambda = testNpmModulesLambda; |
Same issue for me. I just refactored the RestApi creation into it's own stack, and all resource related stacks attempt to add resources and methods to it. But I get
|
I have the same error with @vertti .
|
I tried to exposed lambdas to my DyanmodbStack and it works fine. |
Able to reproduce this with this CDK code - #!/usr/bin/env node
import cdk = require('@aws-cdk/core');
import lambda = require('@aws-cdk/aws-lambda');
import apig = require('@aws-cdk/aws-apigateway');
class FirstStack extends cdk.Stack {
public readonly firstLambda: lambda.Function;
constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
this.firstLambda = new lambda.Function(this, 'firstLambda', {
code: lambda.Code.asset('resources'),
handler: 'index.handler',
runtime: lambda.Runtime.NODEJS_10_X,
});
}
}
interface SecondStackProps extends cdk.StackProps {
readonly lambda: lambda.Function;
}
class SecondStack extends cdk.Stack{
constructor(scope: cdk.Construct, id: string, props: SecondStackProps) {
super(scope, id, props);
const api = new apig.RestApi(this, 'BooksApi');
api.root.addMethod('ANY');
const booksApi = api.root.addResource('books');
const lambdaIntegration = new apig.LambdaIntegration(props.lambda);
booksApi.addMethod('GET', lambdaIntegration);
}
}
const app = new cdk.App();
const first = new FirstStack(app, 'FirstStack');
new SecondStack(app, 'SecondStack', { lambda: first.firstLambda });
app.synth(); followed by running |
Update: Identified that the bug lies with API Gateway specific implementation of the Prepare phase, specifically within the The bug is here - https://github.com/aws/aws-cdk/blob/master/packages/%40aws-cdk/aws-apigateway/lib/deployment.ts#L131. The prepare phase, among other things, identifies intra-stack and cross-stack dependencies and registers them, for future resolution. It can be fully resolved only after the prepare phase is complete. |
…text stack.resolve() works only after the CDK app has been fully prepared. During the 'prepare' phase, it should instead resolve the token partially and within the local context. fixes #3705
1. Token resolution of Deployment construct must not resolve the entire stack, specifically during the prepare phase. stack.resolve() works only after the CDK app has been fully prepared. During the 'prepare' phase, token resolution should instead resolve the token partially and within the local context. 2. Scope the lambda.CfnPermission construct closer to the consumer of the permission rather than being closer to the lambda function. For instance, when a lambda function is being consumed by an APIGateway RestApi Method as a cross-stack reference, placing the lambda.CfnPermission construct closer to the RestApi Method reduces the possibility of cyclic dependencies. fixes #3705, #3000
…n and/or creates cyclic references 1. Token resolution of Deployment construct must not resolve the entire stack, specifically during the prepare phase. stack.resolve() works only after the CDK app has been fully prepared. During the 'prepare' phase, token resolution should instead resolve the token partially and within the local context. 2. Scope the lambda.CfnPermission construct closer to the consumer of the permission rather than being closer to the lambda function. For instance, when a lambda function is being consumed by an APIGateway RestApi Method as a cross-stack reference, placing the lambda.CfnPermission construct closer to the RestApi Method reduces the possibility of cyclic dependencies. fixes #3705, #3000
…n and/or creates cyclic references 1. Token resolution of Deployment construct must not resolve the entire stack, specifically during the prepare phase. stack.resolve() works only after the CDK app has been fully prepared. During the 'prepare' phase, token resolution should instead resolve the token partially and within the local context. 2. Scope the lambda.CfnPermission construct closer to the consumer of the permission rather than being closer to the lambda function. For instance, when a lambda function is being consumed by an APIGateway RestApi Method as a cross-stack reference, placing the lambda.CfnPermission construct closer to the RestApi Method reduces the possibility of cyclic dependencies. fixes #3705, #3000
…ence (#4010) 1. Token resolution of Deployment construct must not resolve the entire stack, specifically during the prepare phase. stack.resolve() works only after the CDK app has been fully prepared. During the 'prepare' phase, token resolution should instead resolve the token partially and within the local context. 2. Scope the lambda.CfnPermission construct closer to the consumer of the permission rather than being closer to the lambda function. For instance, when a lambda function is being consumed by an APIGateway RestApi Method as a cross-stack reference, placing the lambda.CfnPermission construct closer to the RestApi Method reduces the possibility of cyclic dependencies. fixes #3705, #3000
Any updates on this? |
🐛 Bug Report
What is the problem?
I have what I would expect a very typical scenario: APIGateway that exposes several of my lambdas. I frequently have to delete the whole stack and would like to avoid destroying the APIGateway (so as not to change the URL and apikeys). So I wanted to split them to two stacks, one for the APIGateway and one for Lambdas. I first tried with CDK 1.1.0. This caused cyclic dependency errors (which I mentioned here. In hopes of it being fixed, I upgraded to 1.4.0. Now with the same setup I get:
Reproduction Steps
Backend defined with:
where
PostiKioskiLambdaStack
creates a lambda to a publicconfigLambda
property which is given in the props tostackBE
.The lambda in question is put inside a specific vpc:
Verbose Log
https://gist.github.com/vertti/4883548b587774d1f1d2a75e78b640a1
Environment
Other information
There's been lots of fixes done for similar cases where Lambdas are in one stack and for example SNS is in another, all of those seemed to cause cyclic dependency errors.
The text was updated successfully, but these errors were encountered: