Open kkchu791 opened 1 year ago
kkchu791
commented
1 year ago Approaches I've tried:
sriram-mv
commented
1 year ago Thanks for creating this issue, can you share your template and how your code is structured?
Change the name of the resource and it began to work. When I switched it back to the original name, I got the error.
This is super interesting, do you see any changes in the artifacts within .aws-sam/ directory once you change the name of the resource?
kkchu791
commented
1 year ago template.yaml
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
# More info about Globals: https://github.com/awslabs/serverless-application-model/blob/master/docs/globals.rst
Globals:
Function:
Runtime: nodejs18.x
Timeout: 180
Architectures: x86_64
Environment:
Variables:
DB_HOST: process.env.DB_HOST
DB_USER: process.env.DB_USER
DB_PASSWORD: process.env.DB_PASSWORD
DB_DATABASE: process.env.DB_DATABASE
DB_PORT: process.env.DB_PORT
Api:
Cors:
AllowMethods: "'*'"
AllowHeaders: "'*'"
AllowOrigin: "'*'"
Resources:
GetBlocksByDateRangeFunction:
Type: AWS::Serverless::Function
Properties:
Handler: src/handlers/blocks/get-blocks-by-date-range.getBlocksByDateRangeHandler
Runtime: nodejs18.x
Architectures:
- x86_64
Events:
Api:
Type: Api
Properties:
Path: /blocks
Method: GET
GetOpenBlocksByDateRangeFunction:
Type: AWS::Serverless::Function
Properties:
Handler: ./src/handlers/blocks/get-open-blocks-by-date-range.getOpenBlocksByDateRangeHandler
Architectures:
- x86_64
Events:
Api:
Type: HttpApi
Properties:
Path: /blocks/open
Method: GET
CreateBlockFunction:
Type: AWS::Serverless::Function
Properties:
Handler: src/handlers/blocks/create-block.createBlockHandler
Architectures:
- x86_64
Events:
Api:
Type: HttpApi
Properties:
Path: /blocks
Method: POST
# UpdateBlockFunction:
# Type: AWS::Serverless::Function
# Properties:
# Handler: src/handlers/blocks/update-block.updateBlockHandler
# Architectures:
# - x86_64
# Events:
# Api:
# Type: HttpApi
# Properties:
# Path: /blocks/{id}
# Method: PUT
Outputs:
WebEndpoint:
Description: API Gateway endpoint URL for Prod stage
Value: !Sub "https://${ServerlessHttpApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/"I don't see to many changes in the artifacts for .aws-sam besides the function name changing to the new one I changed it to. See in screenshots that the function name is now getBlockssByDateRangeFunction instead of getBlocksByDateRangeFunction.
dineshnagumothu
commented
11 months ago Facing the same issue on M1 Mac. Started initially well, then suddenly got the error with no code changes.
Changed the name of the resource and starts working again.
cunneen
commented
10 months ago I also have this problem (also an M1 Mac), but unlike @dineshnagumothu , renaming the resource didn't work for me.
I strongly suspect the issue is with the lambda runtime harness within the docker image; The error I get is :
node:internal/modules/cjs/loader:1031
throw err;
^
Error: Cannot find module '/var/runtime/index.js'
at Function._resolveFilename (node:internal/modules/cjs/loader:1028:15)
at Function._load (node:internal/modules/cjs/loader:873:27)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
at node:internal/main/run_main_module:22:47 {
code: 'MODULE_NOT_FOUND',
requireStack: []
}
22 Sep 2023 08:49:50,052 [ERROR] (rapid) Init failed error=Runtime exited with error: exit status 1 InvokeID=But if I open a terminal session to the Docker container (which is left running), the /var/runtime/ folder contains an index.mjs file but not an index.js file.
The docker image seems to be this one:
public.ecr.aws/sam/emulation-nodejs16.x:rapid-1.50.0-x86_64
cunneen
commented
10 months ago In my case above, I discovered that I had an outdated version of the SAM CLI that was installed via homebrew, in addition to the one I'd installed via the MacOS package installer.
After uninstalling both, and installing the latest (v1.97.0), debugging my lambda function works nicely for me.
ldu2
commented
9 months ago I’m running into a similar issue on my Mac, OS Ventura 13.6. It happens to all three hello-world ts apps, nodejs14, 16 and 18.
One interesting thing is that after starting the app (any of the three), the first hit to the /hello endpoint gives the classic Error: Cannot find module ‘app’\nRequire stack:\n-/var/runtime/index.mjs”,”stack….
Then the consecutive hits give a different error: Invalid lambda response received: Lambda response must be a valid json.
My sam cli is v1.97.0. I installed with the brew initially, same version, same error. Uninstall that and installed through pkg file. Same error.
This error didn’t happened to me on the most popular python version of the hello world app.
Please let me know if there’s any fix for this issue. It doesn’t seems like there’s any obvious issue on my side. (If you know what I mean) Also removing images and changing resources name didn’t work.
erikhuisman
commented
9 months ago This error happens to me on the sample project:
No problem invoking and run the api for the plain js version
jonaszeu
commented
9 months ago The same problem applies to me, also mac m1 ventura 13.x. Unfortunately, image build and renaming don't help me either. I also tried reinstalling CLI, but that didn't make any difference for me.
TimothyBrehm
commented
9 months ago I'm also seeing this issue. On a Mac. Making nominal code changes sometimes gets it to go away, as does changing the resource name.
--Edit with more details-- This was happening primarily with my authorizer function, but also happened with other functions. Reinstalling the SAM CLI appears to have fixed it. I was also seeing errors with my functions not shutting down in docker I was also experiencing network issues (looks like sam local start-api likes to phone home when kicking off?
GeeWee
commented
8 months ago Also seeing this error on Mac M1 with this starter template. I previously also got it on the plain JS template, but not after updating the CLI to the latest version.
A workaround for me seems to be running sam build manually before running sam local start-api - then it seems to work
keeganstothert
commented
8 months ago Same error on mac (m2) for me the api runs fine for some random amount of time then blows up with this error and requires me to kill and re-run sam local start-api to get it working again
hnnasit
commented
7 months ago Hi, I've tried to reproduce the issue using different init templates (nodejs18.x, ts app) but could not reproduce the same behavior. I installed the latest SAM CLI version (1.105.0) using the native PKG installer on a M1 Ventura 13.5.2 machine. Does the issue still occur in the latest version? If so, can you provide the steps/sample app to reproduce it for us to investigate this further? sam build needs to be run for a ts project to transpile the code to JS before running sam local suite of commands. I'm trying to understand why does it not build the lambda function. Here is my sam --info output:
{
"version": "1.105.0",
"system": {
"python": "3.8.13",
"os": "macOS-13.5.2-arm64-arm-64bit"
},
"additional_dependencies": {
"docker_engine": "24.0.6",
"aws_cdk": "2.103.1 (build 3bb19ac)",
"terraform": "1.5.0"
},
"available_beta_feature_env_vars": [
"SAM_CLI_BETA_FEATURES",
"SAM_CLI_BETA_BUILD_PERFORMANCE",
"SAM_CLI_BETA_TERRAFORM_SUPPORT",
"SAM_CLI_BETA_RUST_CARGO_LAMBDA"
]
}
vini2001
commented
6 months ago I am on M1 Ventura 13.5.1 and was having the same issues described above. I had SAM CLI 1.106.0 installed through the GUI package installer, tried most or all the suggested approaches and nothing worked. I had the issue even with the starter hello world template.
In my case, what ended up working for me was completely uninstalling SAM CLI and reinstalling it using brew. The installed version was the same (1.106.0). Not sure if what did the job was installing using brew or if the issue was with the GUI SAM CLI package installer I had used previously.
Hope this is useful for someone else.
ldu2
commented
4 months ago I’m running into a similar issue on my Mac, OS Ventura 13.6. It happens to all three hello-world ts apps, nodejs14, 16 and 18.
One interesting thing is that after starting the app (any of the three), the first hit to the
/helloendpoint gives the classicError: Cannot find module ‘app’\nRequire stack:\n-/var/runtime/index.mjs”,”stack…. Then the consecutive hits give a different error:Invalid lambda response received: Lambda response must be a valid json.My sam cli is v1.97.0. I installed with the brew initially, same version, same error. Uninstall that and installed through pkg file. Same error.
This error didn’t happened to me on the most popular python version of the
hello worldapp.Please let me know if there’s any fix for this issue. It doesn’t seems like there’s any obvious issue on my side. (If you know what I mean) Also removing images and changing resources name didn’t work.
Round back to this after a couple months. It’s working for me now after I reinstalled sam cli to 1.110.0 through brew. I also reinstalled Docker to the most up to date version, but I didn’t end up using the image version of the example instead I used the zip version. I’m using Hello World Node 18 sample. I didn’t test other Node versions sample since I only needed Node 18 to work for now. Hope this helps for others.
developerKumar
commented
3 months ago I got it working by following the steps:
sam buildsam local start-apiThis issue occurring when using hello world example with typescript.
cjmyles
commented
2 months ago I'm not sure if this is useful to anyone but I had a problem similar to this. I took an existing Typescript Node application I created, and tried to retrofit it so I could run it as an AWS Lambda function. The purpose of the application is to listen for new files being uploaded to a specific bucket, then process the file. The app uses tsc to compile the TypeScript to JavaScript and output the files to a build folder.
My tsconfig.json file looks like this:
{
"compilerOptions": {
"module": "CommonJS",
"esModuleInterop": true,
"target": "ES2017",
"outDir": "./build",
"strict": true
},
"include": ["src/**/*.ts"],
"exclude": ["node_modules"]
}I installed the AWS SAM CLI from the AWS website rather than using Homebrew (as AWS no longer maintains the Homebrew version), and Docker.
I then created a template.yaml file in the root (bucket name redacted for illustration purposes):
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
MyFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: nodejs20.x
CodeUri: ./build
Events:
S3Event:
Type: S3
Properties:
Bucket: [my-bucket-name]
Events: s3:ObjectCreated:*I then modified my index.ts file to export a handler method:
import { S3Event, Context } from "aws-lambda";
export const handler = async (event: S3Event, context: Context): Promise<{ statusCode: number; body: string; }> => {I also created a event.json file that I could use to simulate a new PUT request on the bucket (using the sam generate-event command):
{
"Records": [
{
"eventVersion": "2.0",
"eventSource": "aws:s3",
"awsRegion": "ap-southeast-2",
"eventTime": "1970-01-01T00:00:00.000Z",
"eventName": "ObjectCreated:Put",
"userIdentity": {
"principalId": "EXAMPLE"
},
"requestParameters": {
"sourceIPAddress": "127.0.0.1"
},
"responseElements": {
"x-amz-request-id": "EXAMPLE123456789",
"x-amz-id-2": "EXAMPLE123/5678abcdefghijklambdaisawesome/mnopqrstuvwxyzABCDEFGH"
},
"s3": {
"s3SchemaVersion": "1.0",
"configurationId": "testConfigRule",
"bucket": {
"name": "[my-bucket-name]",
"ownerIdentity": {
"principalId": "EXAMPLE"
},
"arn": "arn:aws:s3:::[my-bucket-name]"
},
"object": {
"key": "[my-key-name]",
"size": 1024,
"eTag": "0123456789abcdef0123456789abcdef",
"sequencer": "0A1B2C3D4E5F678901"
}
}
}
]
}
Finally, I built my code and ran sam local invoke --event event.json (I originally thought I had to run the sam start-api command, but since I'm not using API Gateway, this method is more appropriate). This is where I'd experience the following error:
{"errorType":"Runtime.ImportModuleError","errorMessage":"Error: Cannot find module 'node-xlsx'"...After some trial and error here's what I discovered:
sam build before I run sam local invoke as described by other contributors. I assume this installs dependencies and copies the built files to the Docker image.aws-lambda does not cause the error, which makes me think this library is preinstalled in the Docker image.sam build I saw the warning package.json file not found. Continuing the build without dependencies. I copied my package.json file to the build folder and ran sam build again. This time the warning disappeared and was replaced by Running NodejsNpmBuilder:NpmInstall. Running sam local invoke --event event.json now works without issue.Obviously, copying package.json manually to the build folder isn't a long term solution - so I'll either need to write a script for that as part of the build process, or my project setup isn't quite right. I've been a little lazy with reading the docs on how to set up a TypeScript project with AWS Lambda/SAM so I'll try and find an example Hello World style repository to see how they do it. This is all still a bit of a work in progress, but I thought this might at least help others facing a similar issue.
Edit: Creating a Hello World example (the TypeScript version) using the AWS SAM CLI then modifying it for my needs seemed to fix the issue. See https://aws.amazon.com/blogs/compute/building-typescript-projects-with-aws-sam-cli/ on how to do this.
jghaines
commented
1 month ago I've raised a (possibly tangentially) related issue #7143 BuildMethod: esbuild does not include bundled files where non-source files bundled in an npm library are not included in a typescript/esbuild bundle. A straightforward reproduction is included.
davemanroth
commented
4 weeks ago I got it working by following the steps:
sam buildsam local start-apiThis issue occurring when using hello world example with typescript.
This did it for me, thank you @developerKumar!
After building and starting the local sam server, I'm noticing after I run my lambda
GetBlocksByDateRangeFunction, I get this error in the console.Steps to reproduce:
I'm not sure how I got this behavior to happen.
Observed result:
Expected result:
I'm expecting it to not return an error and not to say
Cannot Find Modulesince the module does exist.Additional environment details (Ex: Windows, Mac, Amazon Linux etc)
Mac
sam --version: SAM CLI, version 1.88.0