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.