(cloudfront): identifier not found

[jordanmonier]

We are using some Cloudfront Functions for our distributions but when we are deploying some changes our pipeline fails because it can not find the cloudfront based on its identifier. The problem is that the identifier that CDK Pipeline has is not correct.

Here's the error :

Resource handler returned message: "Resource of type 'AWS::CloudFront::Function' with identifier 'eu-west-1mdscicdmdOfficeStaticSiteFunctionC23238D5' was not found." (RequestToken: 04588f89-6822-7f5d-22b2-c5c61f92ba7a, HandlerErrorCode: NotFound)

As you can see AWS CDK tries to find this identifier : eu-west-1mdscicdmdOfficeStaticSiteFunctionC23238D5
While the identifier found on the console is : eu-west-1mdscicdmdsOfficeStaticSiteFunctionC23238D5

Environment

• CDK CLI Version : 1.115.0
• Framework Version: 1.115.0
• Node.js Version: 14
• OS : Linux
• Language (Version): Typescript

---

This is 🐛 Bug Report

[ryparker]

Hey @jordanmonier 👋

This is odd. It looks like the CDK generated identifier is missing an s. Could you provide some repro code for this? I'm curious to see exactly how that identifier is being discovered in the CDK code.

[jordanmonier]

Hi @ryparker 👋

I will do that as soon as possible but to quickly resume the hierarchy, my cf function is located inside :

• CDK Pipeline (id: mds-cicd)
• Stage
• Stack (id: mds-main)
• (Custom construct) (id: FrontOffice) (same bug with or without the custom construct)
• Cloudfront (id: WebDistribution)
• Cloudfront Function (id: StaticSite)

Thank you for your feedback !

[daxAKAhackerman]

Hello 👋

I am also affected by this issue. Here's a minimal example of code that can be used to replicate the bug. This was tested with 1.118.0 and 1.117.0.

bin/cf-func-fail.ts

#!/usr/bin/env node
import 'source-map-support/register';
import * as cdk from '@aws-cdk/core';
import { CfFuncFailStack } from '../lib/cf-func-fail-stack';

const app = new cdk.App();
new CfFuncFailStack(app, 'CfFuncFailStack', {});

lib/cf-func-fail-stack.ts

import * as cdk from '@aws-cdk/core';
import { CfFuncConstruct } from './constructs/cf-func';

export class CfFuncFailStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    new CfFuncConstruct(this, 'CfFuncConstruct')
  }
}

lib/constructs/cf-func.ts

import * as cdk from '@aws-cdk/core'
import * as cloudfront from '@aws-cdk/aws-cloudfront'

export class CfFuncConstruct extends cdk.Construct {
  constructor (scope: cdk.Stack, id: string) {
    super(scope, id)

    new cloudfront.Function(this, 'RedirectionCloudFrontFunction', {
      code: cloudfront.FunctionCode.fromFile({
        filePath: 'lib/cloudfront-functions/my_func.js'
      })
    })
  }
}

lib/cloudfront-functions/my_func.js

function handler(event) {
    console.log('test2')
}

The bug is erratic. To replicate it, deploy the stack, modify the javascript function (changing the test2 string is sufficient), and redeploy. If the bug doesn't occur, change the string again and deploy again (I use npx cdk deploy to deploy).

It takes 2-3 tries, but you eventually get the following error:

8:46:54 AM | UPDATE_FAILED        | AWS::CloudFront::Function | CfFuncConstructRed...ntFunctionF201D1DA
Resource handler returned message: "Resource of type 'AWS::CloudFront::Function' with identifier 'us-east-1CfFuncFaiectionCloudFrontFunctionD10DE1AD' was not found." (RequestToken: 2a405fda-4c21-6cff-0
7d0-32d577fcd481, HandlerErrorCode: NotFound)

There seems to be a mismatch between the resource name that CDK tries to update (us-east-1CfFuncFailectionCloudFrontFunctionD10DE1AD) and the real one (us-east-1CfFuncFaiectionCloudFrontFunctionD10DE1AD)

For now, the workaround is just to try again when it fails, and it will usually work within 1-2 retries.

If you need any more information, let me know!

[njlynch]

I believe this is likely a duplicate of #15523. Can you try the workaround listed there, and see if that resolves it? If so, we can close this as a duplicate and track the fix there.

[daxAKAhackerman]

Yep, this looks like the same issue. The workaround mentioned does seem to fix the problem.

Thank you! I should have looked a bit harder 😅

[njlynch]

Thanks for the confirmation. I'm going to assume the same for @jordanmonier . Closing -- feel free to ping me if the linked issue is distinct from the original issue here. Otherwise, please track the status on #15523 .

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.