(core): NodejsFunction causes failure in `cdk ls`

Using NodejsFunction to create a Lambda Authorizer, cdk synth works as expected and a ZIP file is created and referenced in my build/cdk.out folder.

When I do cdk ls, the lambda references build/cdk.out/<The entire path to my root folder>.zip instead of the bundle.

Reproduction Steps

app.ts

import * as cdk from 'monocdk';
import * as lambda from 'monocdk/aws-lambda-nodejs';

const app = new cdk.App();

class ServiceInfraStack extends Stack {
  constructor(parent: cdk.Construct, name: string, props: DeploymentStackProps) {
    super(parent, name, props);
    new lambda.NodejsFunction(this, 'secret-key-auth');
  }
}

new ServiceInfraStack(app, 'beta', {
  stackName: `Test-Infra`,
});

app.secret-key-auth.ts

exports.handler = async (event: any) => {
  return {
    principalId: 'user',
    policyDocument: {
      Version: '2012-10-17',
      Statement: [
        {
          Action: 'execute-api:Invoke',
          Effect: event.headers.serverapikey === 'ok' ? 'Allow' : 'Deny',
          Resource: event.routeArn,
        },
      ],
    },
  };
};

cdk.json

{
  "app": "node dist/lib/app",
  },
  "output": "build/cdk.out"
}

What did you expect to happen?

Expected cdk ls to show the name of the stack.

What actually happened?

events.js:291
      throw er; // Unhandled 'error' event
      ^

Error: ENOENT: no such file or directory, open 'build/cdk.out/Volumes/workspaces/Showrunner/src/P10ShowrunnerDataServiceCDKCopy.zip'
Emitted 'error' event on WriteStream instance at:
    at errorOrDestroy (/Volumes/workspaces/Showrunner/src/P10ShowrunnerDataServiceCDKCopy/node_modules/@amzn/pipelines/node_modules/readable-stream/lib/internal/streams/destroy.js:98:101)
    at WriteStream.onerror (/Volumes/workspaces/Showrunner/src/P10ShowrunnerDataServiceCDKCopy/node_modules/@amzn/pipelines/node_modules/readable-stream/lib/_stream_readable.js:704:47)
    at WriteStream.emit (events.js:314:20)
    at /Volumes/workspaces/Showrunner/src/P10ShowrunnerDataServiceCDKCopy/node_modules/@amzn/pipelines/node_modules/graceful-fs/graceful-fs.js:303:14
    at /Volumes/workspaces/Showrunner/src/P10ShowrunnerDataServiceCDKCopy/node_modules/@amzn/pipelines/node_modules/graceful-fs/graceful-fs.js:333:16
    at FSReqCallback.oncomplete (fs.js:156:23) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: 'build/cdk.out/Volumes/workspaces/Showrunner/src/P10ShowrunnerDataServiceCDKCopy.zip'
}

Environment

• CDK CLI Version : 1.83.0
• Framework Version: 1.81.0
• Node.js Version: v12.20.0
• OS : MacOS 10.15.7
• **Language (Version): TypeScript 3.9.7 **

Other

I have found that I can prevent this by hacking: https://github.com/aws/aws-cdk/blob/master/packages/%40aws-cdk/core/lib/asset-staging.ts#L166

I replace skip with false and cdk ls now behaves properly.

---

This is 🐛 Bug Report

[ryparker]

Hey @smaxwell-amazon 👋🏻

I noticed that you’re passing in the the entry path as the id argument of the NodejsFunction constructor.

Check out these docs: NodejsFunction class | NodejsFunction props

To fix your example. change your app.ts initalization of lambda.NodejsFunction from:

new lambda.NodejsFunction(this, 'secret-key-auth');

To:

new lambda.NodejsFunction(this, 'desired-lambda-id', {
	entry: 'secret-key-auth'
});

Please let me know if this fixes your problem.

[wimlewis-amazon]

@ryparker I can’t reproduce the bug in the top comment either, whether in the current version or the version it was reported against. Can you reproduce it in an earlier version of the CDK? I’m beginning to think that the problem is actually in one of the non-CDK subclasses of Stage that both @smaxwell-amazon and I are using (check the pre-edit version of the issue submission), not with the code in the CDK.