Bug: Importing SF client from aws-sdk v2 causes Lambda unresponsive when using esbuild

[Drodevbar]

Description:

Importing SF client from aws-sdk v2 causes Lambda unresponsive when using esbuild.

Steps to reproduce:

1. sam init
   1.1. AWS Quick Start Templates
   1.2. Hello World Example
   1.3. nodejs16.x
   1.4. Zip
   1.5. Hello World Example TypeScript
2. cd <project>/hello-world
3. modify package.json and add "aws-sdk": "^2.1342.0" into dependencies
4. npm i
5. modify hello-world/app.ts as below:

import { StepFunctions } from 'aws-sdk';

export const lambdaHandler = async () => {
    console.log("Before initializing SF client");
    const sfClient = new StepFunctions();
    console.log("After initializing SF client");
};

6. cd ..
7. sam build
8. sam deploy --guided and confirm the deployment with the defaults
9. head over to AWS console and locate deployed lambda
10. execute the Lambda

Observed result:

Lambda times out. If the function's timeout is increased to let's say 30 seconds, it runs out of memory (128MB by default in my case). Pre-initializing logs are not displayed, which means that Lambda probably hangs out when importing StepFunctions client.

I checked other AWS-SDK v2 clients like S3, DocumentClient and it works without any issue.

I've also noticed that when I change

import { StepFunctions } from 'aws-sdk';

into the below:

import StepFunctions from 'aws-sdk/clients/stepfunctions';

it starts working.

Expected result:

Importing & initializing StepFunctions from aws-sdk v2 works as expected and doesn't cause lambda timeouts/memory outages - basically doesn't make Lambda not responsive.

Additional environment details (Ex: Windows, Mac, Amazon Linux etc)

1. OS: macOS-13.0.1-x86_64-i386-64bit
2. sam --version: SAM CLI, version 1.76.0
3. AWS region: eu-west-1
4. esbuild: "esbuild": "^0.14.14"

{
  "version": "1.76.0",
  "system": {
    "python": "3.11.2",
    "os": "macOS-13.0.1-x86_64-i386-64bit"
  },
  "additional_dependencies": {
    "docker_engine": "20.10.20",
    "aws_cdk": "2.69.0 (build 60a5b2a)",
    "terraform": "1.0.0"
  }
}

[mildaniel]

Thanks @Drodevbar for reporting. I'm going to try to repro and see where this issue could be coming from.

[mildaniel]

I looked further into this and it seems as though the bundle size created using the deconstructing import syntax is significantly larger than that of the non-deconstructing syntax. I tested it by running build with both and comparing the size of the .aws-sam/build/HelloWorldFunction directory both times.

Deconstructing syntax size:

du -h .aws-sam/build/HelloWorldFunction/
9.5M	.aws-sam/build/HelloWorldFunction/

Non-deconstructing size:

du -h .aws-sam/build/HelloWorldFunction/
1.4M	.aws-sam/build/HelloWorldFunction/

I'm not sure why this happens exactly, since I would assume that the tree-shaking functionality of esbuild would handle it either way. In the meantime, I would recommend using the import StepFunctions from 'aws-sdk/clients/stepfunctions'; synax and I'll look closer into if this is an issue with AWS SAM CLI and esbuild.