Container lambda function gets DD_LAMBDA_HANDLER unset

[klingenm]

Expected Behavior

The following code;

    const func = new Function(this, 'function', {
      runtime: Runtime.FROM_IMAGE,
      handler: Handler.FROM_IMAGE,
      architecture: Architecture.ARM_64,
      environment: {
        DD_LAMBDA_HANDLER: 'dist/index.handler',
      },
      memorySize: 1024,
      timeout: Duration.seconds(30),
      code: Code.fromEcrImage(repository, {
        tagOrDigest: imageInfo.sha,
        entrypoint: ['aws-lambda-ric'],
        cmd: ['node_modules/datadog-lambda-js/dist/handler.handler'],
        workingDirectory: '/opt/applicationpath',
      }),
    });

    const datadog = new Datadog(this, 'dd', {
      site: DDLambdaConfig.DATADOG_SITE,
      apiKeySecret: Secret.fromSecretCompleteArn(
        this,
        'apiKeySecret',
        lambdaExtensionApiKeyArn,
      ),
      extensionLayerVersion: DDLambdaConfig.DATADOG_EXTENSION_VERSION,
      nodeLayerVersion: DDLambdaConfig.DATADOG_NODE_LAYER_VERSION,
      pythonLayerVersion: DDLambdaConfig.DATADOG_PYTHON_LAYER_VERSION,
      env: this.environmentName,
      service: this.serviceName,
      version: this.platformVersion,
      addLayers: false,
    });

    datadog.addLambdaFunctions([func]);

should work (or break).

Actual Behavior

The DD_LAMBDA_HANDLER environment variable is forcibly overridden with the value of
the function defaultChild.handler, which for a container lambda function is undefined (and has to be ´undefined`).

Synth and deploy works, but the DD_LAMBDA_HANDLER env variable has disappeared, so function cant run.

datadog-cdk-constructs/src/redirect.ts

Line 48 in 0e1d841

const originalHandler = cfnFuntion.handler as string;

From reading the code I could figure out that I should disable the redirect. But it was quite hard to find out.

There is documentation for how to use CDK and how to install the extension in a container but not how to combine the two.

I would expect that doing what I did should cause error on synth, or the redirect would be disabled by default if function is configure with image (func.runtime.runtimeEquals(Runtime.FROM_IMAGE).

Good thing you keep this open source, so one can figure out what's happening :D

Steps to Reproduce the Problem

1. write the code
2. run the code
3. be confused

Specifications

• construct version v2-1.16.1

[klingenm]

Found another thing related to image based lambdas. You prepend the "LAMBDA_TASK_ROOT" to the "handler" when including it. We have a common image where we are bundling code for many lambdas, so we don't set the env var in the image (instead we set the working directory in the lambda image config), and it is reserved, so it can be set in the configuration. Found a workaround for this as well, by setting the "DD_LAMBDA_HANDLER" to a full path /full/path/to/the/file.handler. Not sure if it falls under the same image lambda pitfalls umbrella.

[clifordshelton]

Hi Magnus! Thanks for the detailed explanation. That makes total sense. We will look into updating our CDK construct to not perform the redirect for container lambdas. As for the second comment of prepending LAMBDA_TASK_ROOT, let me discuss with the team and get back to you.

Sorry about the delay in response. We lost track of this issue and found it in a more widespread triage.

[klingenm]

Since I found a workaround I forgot about this one too. Must have missed your first comment. Saw the notification now that you assigned someone to it :)