(aws-cloudfront): CloudFront IFunction interface is structurally compatible with Lambda's IFunction, but not compatible in AWS

[moltar]

What is the problem?

I am able to assign a Lambda function to CloudFront function (matching TypeScript interfaces), but when the solution is deployed, it produces an error, as Lambda functions cannot be used as CloudFront functions.

Reproduction Steps

new cloudfront.Distribution(this, "CloudFrontDistribution", {
  defaultBehavior: {
    origin: new S3Origin(bucket),
    functionAssociations: [
      {
        // this does not result in error
        function: new NodejsFunction(this, "Fn", {
          entry: 'cf.js',
        }),
        eventType: cloudfront.FunctionEventType.VIEWER_REQUEST
      }
    ]
  },
})

What did you expect to happen?

Interfaces to be incompatible and get an error in the IDE and at build time.

What actually happened?

No error was produced in the IDE or at build time.

Error happened during the deployment:

Invalid request provided: 2 validation errors detected: Value 'arn:aws:lambda:ap-northeast-1:123456:function:Fn220341F76-xxx' at 'distributionConfig.cacheBehaviors.items.1.member.functionAssociations.items.1.member.functionARN' failed to satisfy constraint: Member must satisfy regular expression pattern: arn:aws:cloudfront::[0-9]{12}:function/[a-zA-Z 0-9-_]{1,64}$; Value 'arn:aws:lambda:ap-northeast-1:123456:function:Fn220341F76-h4X9p0uP7M5E' at 'distributionConfig.cacheBehaviors.items.1.member.functionAssociations.items.1.m ember.functionARN' failed to satisfy constraint: Member must have length less than or equal to 108 (Service: CloudFront, Status Code: 400, Request ID: 5fcc4d15-74b0-4a55-9845-8631a395fdb2, Extended Request ID: null)"

CDK CLI Version

1.126.0 (build f004e1a)

Framework Version

1.126.0

Node.js Version

v14.17.5

OS

macOS

Language

Typescript

Language Version

TypeScript 4.4.3

Other information

No response

[peterwoodworth]

Thanks for submitting this issue @moltar,

Seems to me like this is a consequence of the lambda IFunction having all of the properties that cloudfront's IFunction has. I'm not sure there's anything we can do about this, and it's more a consequence of how the language works. @njlynch is this accurate?

[moltar]

Seems to me like this is a consequence of the lambda IFunction having all of the properties that cloudfront's IFunction has.

That is correct.

I'm not sure there's anything we can do about this, and it's more a consequence of how the language works. @njlynch is this accurate?

There is a way to do this, it's a bit hack-ish, using nominal typing.

[njlynch]

Yeah, just about the only way to fix this would be to add a conflicting parameter between the two (e.g., an extra prop to CloudFront's IFunction) just for the sake of avoiding this. This might naturally happen in the future, as new capabilities are added to CloudFront Functions.

[moltar]

Probably too late, but at least aming the interface differently would be good.

Maybe ICloudFrontFunction, as it is only applicable to CF anyways.

[github-actions]

This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[moltar]

Not stale.

GitHub stale bot considered harmful

[ashishdhingra]

@moltar Good afternoon. As mentioned in the #16885 (comment), this is a consequence on how TypeScript works. Are you able to see the same issue in other languages (such as .NET, Java or Python)? I'm unsure if it is feasible to raise the error during build time.

[laurelmay]

I don't think it'd be unreasonable to bring functionRuntime from FunctionAttributes in as a property of cloudfront.IFunction -- that (at least nullably) has to be defined for both imported and created functions. That attribute does not exist for lambda.IFunction. That structural difference should appease languages that allow structural equivalence for types.

[ashishdhingra]

I don't think it'd be unreasonable to bring functionRuntime from FunctionAttributes in as a property of cloudfront.IFunction -- that (at least nullably) has to be defined for both imported and created functions. That attribute does not exist for lambda.IFunction. That structural difference should appease languages that allow structural equivalence for types.

@kylelaker FunctionProps does have the Runtime attribute.

[laurelmay]

@kylelaker FunctionProps does have the Runtime attribute.

Sure, but that's not exposed in lambda.IFunction (at least not with the name I proposed here) 🤷‍♀️ It's an option that's currently available to solve the issue. This issue is about the IFunction interfaces.

I didn't look into whether FunctionProps has the same problems but I thought those were already incompatible.