(aws-appsync) Upgrading from v1.70.0 to 1.85.0 resulted in AppSync GraphQL endpoints not being wired-up correctly

[asnaseer-resilient]

We had an existing, working AppSync GraphQL service that was deployed using CDK v1.70.0.

I reviewed all the release notes from v1.70.0 to v1.85.0 yesterday and did not spot anything that would cause a breaking change to this deployment. I therefore upgraded to CDK v1.85.0 yesterday but found that it had not wired-up any of the Query or Mutation Resolvers to the Lambda Data Source that we use.

I then reverted to v1.70.0 but found that it had not fixed the issue I spotted. I finally undeployed and then re-deployed to get the service back to normality.

Could this be a bug in the CDK or have I missed something in the release notes that I am supposed to follow first?

Reproduction Steps

Described above.

What did you expect to happen?

My AppSync GraphQL service to be deployed correctly.

What actually happened?

None of our Query or Mutation Resolvers to the Lambda Data Source that we use were wired-up.

Environment

• CDK CLI Version : v1.85.0
• Framework Version: v1.85.0
• Node.js Version: 12.14.1
• OS : Run in CircleCI using image circleci/node:12.14.1
• Language (Version): TypeScript (4.1.3)

Other

---

This is 🐛 Bug Report

[pierre-vr]

We encountered the same issue when upgrading from 1.74.0 to 1.83.0. Our resolvers where not attached anymore (as described here) using BaseDataSource.createResolver().

Simply downgrading the version did not solve the issue. So far we had to rewire manually in the AWS console.

Hence, the bug may have been introduced by a version > 1.74.0 and <= 1.83.0.

[BryanPan342]

Hm.. I think this is probably a bug that was introduced in my PR #10111 to allow for appsync functions

To be completely honest, I wrote this code a while before it was merged, but I'm guessing the problem is coming from the fact that the CfnResolverProps.dataSourceName is not getting set properly

interestingly, I'm not getting errors on the tests we have currently.. in fact, the only change is in the name of the Cfn resource because we are creating the resolvers from the GraphqlApi instead of the DataSource itself.

can I ask if dataSourceName is getting set to the right name or if it's undefined (you can check by looking at the CfnTemplate)

if it's undefined there is a problem with the props between DataSource -> GraphqlAPI

if it's not the right name, the problem is with DataSource

---

also a sample code snippet of how you are creating resolvers would be greatly appreciated!

[asnaseer-resilient]

@BryanPan342 Unfortunately I do not have the original outputs as I had to rapidly revert to get our service back up and running. A snippet of code that is used for this is shown below:

import * as cdk from '@aws-cdk/core';
import * as cdkAppsync from '@aws-cdk/aws-appsync';
    ...
    const lambdaApiResolverDataSource = graphQlApi.addLambdaDataSource('LambdaApiResolverDataSource', lambdaApiResolverFunction, {
      name: 'DataSource',
      description: `Resolves GraphQL requests for ${product}`
    });

    lambdaApiResolverDataSource.createResolver(
    {
      typeName: 'Mutation',
      fieldName: 'createCallFlow',
      requestMappingTemplate: cdkAppsync.MappingTemplate.lambdaRequest(
        `{
          "parent": $util.toJson($ctx.source),
          "field": $util.toJson($ctx.info.fieldName),
          "origin": "$ctx.request.headers.origin",
          "accessToken": "$ctx.request.headers.authorization",
          "userCustomerId": $util.toJson($ctx.identity.claims["custom:acu_cust_id"]),
          "userEmail": $util.toJson($ctx.identity.claims["email"]),
          "userIdentity": $util.toJson($ctx.identity),
          "arguments": $util.toJson($ctx.arguments)
        }`
      ),
      responseMappingTemplate: cdkAppsync.MappingTemplate.lambdaResult()
    });

[BryanPan342]

@asnaseer-resilient thanks for the code snippet

Ah i think i see the issue.. how many data sources do you have that are named "DataSource"?

[asnaseer-resilient]

@BryanPan342 Just the one. We have several AppSync GraphQL services deployed. In each of these, there is a single lambda function (named DataSource as above) that resolves all the queries and mutations.

So each CloudFormation stack has a similar setup.

In the "real" code we have actually extracted some common CDK patterns into a helper, so the "real" code looks more like this:

    const lambdaApiResolverDataSource = graphQlApi.addLambdaDataSource('LambdaApiResolverDataSource', lambdaApiResolverFunction, {
      name: 'DataSource',
      description: `Resolves GraphQL requests for ${tags!.product}`
    });

    lambdaApiResolverDataSource.createResolver(CDK_UTILS.graphQlResolver('Mutation', 'createCallFlow'));
    lambdaApiResolverDataSource.createResolver(CDK_UTILS.graphQlResolver('Query', 'getCallFlow'));
    lambdaApiResolverDataSource.createResolver(CDK_UTILS.graphQlResolver('Query', 'listCallFlows'));
    lambdaApiResolverDataSource.createResolver(CDK_UTILS.graphQlResolver('Mutation', 'updateCallFlow'));
    lambdaApiResolverDataSource.createResolver(CDK_UTILS.graphQlResolver('Mutation', 'assignSmartnumbersToCallFlow'));
    lambdaApiResolverDataSource.createResolver(CDK_UTILS.graphQlResolver('Query', 'hasJobCompleted'));
    lambdaApiResolverDataSource.createResolver(CDK_UTILS.graphQlResolver('Mutation', 'deleteCallFlow'));

[BryanPan342]

Hm.. okay the only thing that I can think of that might be messing with them being attached is the fact that the Cfn id is now changed.. these id's are based on the order in which CDK generates them.. similar to like a tree

So because resolvers were generated from DataSources before, the path looked like [Api][DataSource][Resolver] but now since we have made Resolvers stem directly from GraphqlApi, it will mutate the id to be [Api][Resolver]. I'll test out a couple of things and see if there are any changes!

[BryanPan342]

@asnaseer-resilient okay, after some tests i found that because the id's of the components are the same, I actually ran into the following problem:

6:33:38 PM | CREATE_FAILED        | AWS::AppSync::Resolver      | ApiQuerygetTestsResolver025B8E
0A
Only one resolver is allowed per field. (Service: AWSAppSync; Status Code: 400; Error Code: BadR
equestException; Request ID: 8217847d-98c4-428d-ae6d-7370d07708e9; Proxy: null)

Seems to me like the issue lies with the way CloudFormation handles resource creation.

@MrArnoldPalmer what do you think is the best way to combat this? I remember discussing the reasoning behind having the resolvers be descended from GraphqlApi. But we are also at a point where, if we revert back to the old way, we will screw over all the new people who are using cdk w/ appsync.

[asnaseer-resilient]

@BryanPan342 Could you add a feature flag to cdk.context.json to allow old-style behaviour?

[p0wl]

We are also running into this and we need to upgrade to 1.88.0 (from 1.76.0) because of another bug. This bug is blocking us from doing the upgrade right now.

So after reading this, the problem seems to be that Cloudformation wants to attach the new resolvers (=with new name) before the old ones are beeing detached (as they will be deleted in a different step).

So to fix this, I would need to detach all resolvers manually before the deploy, which results in a downtime. I really would want to avoid that. Also, downgrading resulted in some vtl resolves not being attached any longer, so that breaks as well :/

(thanks for your work on resolver functions @BryanPan342 , I was trying to do a pipeline resolver a month back and it was horrible, your change looks great!)