This is a (Feature Proposal)

Description

For bug reports:

• What went wrong?

I had a bug that cloudformation just stuck at UPDATE_ROLLBACK_FAILED. So I should to delete the stack and deploy serverless again. But now I got another problem:

Serverless Error ---------------------------------------

    An error occurred while provisioning your stack: AvailableDynamoDbTable
    - Available already exists.

• What did you expect should have happened?

I think that database is too critical in production level to wont use Retain, In a simple wrong deploy or remove the stack can banish all your tables, wrong deploy can easily rollback but data is really critical.

So I suggest to have something like: serverless deploy --skipResources, so it wlll skip the resources that already exist and cloudformation wont bring that error.

Similar or dependent issues:

• #3148

Additional Data

• Serverless Framework Version you're using: 1.6.1
• Operating System: Mac OS El Capitan
• Stack Trace:
• Provider Error messages:

I’ve been spending time recently trying to remove Admin rights as a requirement for sls deployments. Still a work in progress, but so far I have this policy that I can attach to any “serverless-agent” AWS user, so that the serverless-agent user is empowered enough to deploy:

    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cloudformation:Describe*",
                "cloudformation:List*",
                "cloudformation:Get*",
                "cloudformation:PreviewStackUpdate"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloudformation:CreateStack",
                "cloudformation:UpdateStack",
                "cloudformation:DeleteStack"
            ],
            "Resource": "arn:aws:cloudformation:*:*:stack/${project}*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "lambda:Get*",
                "lambda:List*",
                "lambda:CreateFunction"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "lambda:AddPermission",
                "lambda:CreateAlias",
                "lambda:DeleteFunction",
                "lambda:InvokeFunction",
                "lambda:PublishVersion",
                "lambda:RemovePermission",
                "lambda:Update*"
            ],
            "Resource": "arn:aws:lambda:*:*:function:${project}*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "lambda:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "apigateway:GET"
            ],
            "Resource": [
                "arn:aws:apigateway:*::/restapis"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "apigateway:GET",
                "apigateway:POST",
                "apigateway:PUT",
                "apigateway:DELETE"
            ],
            "Resource": [
                "arn:aws:apigateway:*::/restapis/*/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:PassRole"
            ],
            "Resource": "arn:aws:iam::*:role/*"
        },
        {
            "Effect": "Allow",
            "Action": "kinesis:*",
            "Resource": "arn:aws:kinesis:*:*:stream/${project}*"
        },
        {
            "Effect": "Allow",
            "Action": "iam:*",
            "Resource": "arn:aws:iam::*:role/${project}*"
        },
        {
            "Effect": "Allow",
            "Action": "sqs:*",
            "Resource": "arn:aws:sqs:*:*:${project}*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "events:Put*",
                "events:Remove*",
                "events:Delete*"
            ],
            "Resource": "arn:aws:events:*:*:rule/${project}*"
        }
    ]
}

Right now, I'm focused on a single policy that can deploy to all stages. But some enterprises may need this IAM policy to allow dev and staging deployments, but limit who can deploy to production. So, I've also been experimenting with adding "${stage}" to some of the resource ARNs, but don't have it fully worked out yet. For example:

"Resource": "arn:aws:events:*:*:rule/${project}-${stage}*"

There are still a few places where the permissions could be narrowed further. Specifically, the REST API section allows delete of ALL apis right now. And the lambda permissions are too broad. But I’ve had some annoying technical issues trying to narrow those two sections.

The API Gateway policy is still broad because you must have the 'api-id' in the ARN. But you don't know that until a deployment generates it. So on the surface, seems like a chicken/egg problem to me, but maybe there is a way to supply that api-id, instead of having AWS generate it.

And the lambda permissions are still broad because I can't see the particular Arn it is trying to manipulate to add an event mapping to a lambda, and the obvious ARNs don't work. Maybe there is a way to show the ARN being accessed in serverless, when the deployment fails so that I can add it to the policy, but no luck so far.

As I said, still a work in progress, so use with caution. Will post back any further 'narrowing' as I figure it.

This is a Feature Proposal

Description

I'd like to deploy many microservices to one API Gateway, but currently I'm not able to as the template is creating a new Gateway for every service. Would it be possible to change the behaviour? I may create a Pull Request for this if you agree

Topic on the forum: http://forum.serverless.com/t/multiple-services-behind-a-single-api-gateway/191

In version 2.14 configSchema.jscontains useDotenv: { const: true }, but falseis a valid value cf https://www.serverless.com/framework/docs/providers/aws/guide/serverless.yml/

Also deprecation warning LOAD_VARIABLES_FROM_ENV_FILES should not be triggered when useDotenv=false.

This is a Bug Report

Description

When using the serverless deploy --aws-profile or using the EXPORT AWS_PROFILE=<profile>; serverless deploy or the AWS_PROFILE=<profile> serverless deploy it only reads from the credentials file, but that should also be reading from the config file like the default aws cli tools does.

For example I have the following two files

~/.aws/config
[default]
aws_access_key_id = <>
aws_secret_access_key = <>

~/.aws/credentials
[profile default]
output = json
region = us-east-1

[profile dev]
role_arn = <cross_account_role>
source_profile = <another_profile>
mfa_serial = <mfa_serial>
region = us-east-1
output = json

If I run serverless deploy --profile dev it will fail with

ServerlessError: AWS provider credentials not found. You can find more info on how to set up provider credentials in our docs here: https://git.io/vXsdd

Then I tried AWS_PROFILE=dev serverless deploy and it failed with the above error

And finally I ran export AWS_PROFILE="dev" && export AWS_REGION=us-east-1 and then ran the serverless deploy and the same error occur.

So reading more in depth the above small link and talking to people on Gitter I moved that dev profile to ~/.aws/config, creating new keys since the previous used a cross account mfa role.

Its my experience using Troposphere and tools that rely on AWS Profiles, they should be looking into all of them and if they have an mfa, request the code about it.

Additional Data

• Serverless Framework Version you're using: 1.15.3
• Operating System: Mac OS 10.12.5
• Stack Trace: Shown above

Workaround

Create an additional profile and store it inside the ~/.aws/config to use and then you can refer to it using --profile

Serverless Framework Version: 1.0.0-beta.1.1

How do I enable CORS so I can access my functions? I can't find anything in the docs, and the CORS plugin seems to not be relevant to the current version of Serverless.

APIG Response/Request templates options are now missing in V1, we need to bring back this functionality. In v0.5.6 we let users define their velocity templates as strings in the s-function.json json file, which was very hard to maintain. We can still do that in v1 using our serverless.yaml file, but it'd still be really hard to maintain all the templates in all endpoints in all functions in a single file.

Someone suggested before that we should let users define their velocity template in a .vm file and just reference it in the APIG config object in serverless.yaml (or s-function.json). I think this will make it much easier to deal with APIG and will provide super flexibility.

Another option is for Serverless to provide an abstraction layer on top of velocity templates so that users don't have to provide velocity templates at all, just some yaml config options that will be compiled into valid velocity templates. This will probably be better UX, but will be much less flexible, and users with specific needs might get stuck.

Or maybe we can do something in between. Thoughts...? cc/ @flomotlik @pmuens @ac360

Parent Issue: https://github.com/serverless/serverless/issues/1408

Description

I have 8 times ${cf:..} in my serverless.yaml and I get 3 out of 5 times "Rate exceeded" while running serverless. I suppose I've reached a limit for cloudformation's API calls (DescribeStack for instance). Is there any chance to avoid this error except of increase my limits? Why doesn't serverless calls the api only once for all stacks? Or at least only once per stack?

Last but not least: Which limit do I reach? I don't know which one mentiond on aws limits

For bug reports:

• What went wrong? I run "serverless deploy -v" and I get an error "Rate exceeded"
• What did you expect should have happened? deploying without that error
• What was the config you used?

custom:
  stage: ${cf:StackA.StagePrefix}
  vpcStackName: ${cf:StackA.VpcStackName}
  topicGeneral: ${cf:StackB.In}
  topicBs: ${cf:StackC.In}
  dnsName: ${cf:StackD.LoadBalancerDNSName}
  securityGroupIds: ${cf:StackD.AlbSecurityGroup}
  privateSubnet1: ${cf:StackE.PrivateSubnet1}
  privateSubnet2: ${cf:StackE.PrivateSubnet2}

• What stacktrace or error message from your provider did you see?

> sls package
 
  Serverless Error ---------------------------------------
 
     Rate exceeded
 
  Get Support --------------------------------------------
     Docs:          docs.serverless.com
     Bugs:          github.com/serverless/serverless/issues
     Forums:        forum.serverless.com
     Chat:          gitter.im/serverless/serverless
 
  Your Environment Information -----------------------------
     OS:                 linux
     Node Version:       6.9.1
     Serverless Version: 1.14.0

For feature proposals:

• What is the use case that should be solved. The more detail you describe this in the easier it is to understand for us.
• If there is additional config how would it look

Similar or dependent issues:

• #3339

Additional Data

• Serverless Framework Version you're using: 1.14.0
• Operating System: Fedora / Linux
• Stack Trace: Rate exceeded
• Provider Error messages:

This is a Bug Report

Description

• What went wrong?

After upgrading my project from 0.5.6 to 1.0.0 I attempted to deploy and received this error:

Template format error: Number of resources, 202, is greater than maximum allowed, 200

• What did you expect should have happened?

I expect that this should have worked since there is no limitation on AWS that should forbid this, and it was working on 0.5.6. Serverless should break up the template resources automatically to make this possible.

With the current method you are forced to break up the service, which should not be necessary. This causes problems with general project structure, custom domain mapping, and shared dependencies.

• What was the config you used?

The example config below will generate the error by creating 65 endpoints.

service: test

provider:
  name: aws
  runtime: nodejs4.3

functions:
  hello:
    handler: handler.hello
    events:
      - http:
          path: e00
          method: get
          cors: true
      - http:
          path: e01
          method: get
          cors: true
      - http:
          path: e02
          method: get
          cors: true
      - http:
          path: e03
          method: get
          cors: true
      - http:
          path: e04
          method: get
          cors: true
      - http:
          path: e05
          method: get
          cors: true
      - http:
          path: e06
          method: get
          cors: true
      - http:
          path: e07
          method: get
          cors: true
      - http:
          path: e08
          method: get
          cors: true
      - http:
          path: e09
          method: get
          cors: true
      - http:
          path: e10
          method: get
          cors: true
      - http:
          path: e11
          method: get
          cors: true
      - http:
          path: e12
          method: get
          cors: true
      - http:
          path: e13
          method: get
          cors: true
      - http:
          path: e14
          method: get
          cors: true
      - http:
          path: e15
          method: get
          cors: true
      - http:
          path: e16
          method: get
          cors: true
      - http:
          path: e17
          method: get
          cors: true
      - http:
          path: e18
          method: get
          cors: true
      - http:
          path: e19
          method: get
          cors: true
      - http:
          path: e20
          method: get
          cors: true
      - http:
          path: e21
          method: get
          cors: true
      - http:
          path: e22
          method: get
          cors: true
      - http:
          path: e23
          method: get
          cors: true
      - http:
          path: e24
          method: get
          cors: true
      - http:
          path: e25
          method: get
          cors: true
      - http:
          path: e26
          method: get
          cors: true
      - http:
          path: e27
          method: get
          cors: true
      - http:
          path: e28
          method: get
          cors: true
      - http:
          path: e29
          method: get
          cors: true
      - http:
          path: e30
          method: get
          cors: true
      - http:
          path: e31
          method: get
          cors: true
      - http:
          path: e32
          method: get
          cors: true
      - http:
          path: e33
          method: get
          cors: true
      - http:
          path: e34
          method: get
          cors: true
      - http:
          path: e35
          method: get
          cors: true
      - http:
          path: e36
          method: get
          cors: true
      - http:
          path: e37
          method: get
          cors: true
      - http:
          path: e38
          method: get
          cors: true
      - http:
          path: e39
          method: get
          cors: true
      - http:
          path: e40
          method: get
          cors: true
      - http:
          path: e41
          method: get
          cors: true
      - http:
          path: e42
          method: get
          cors: true
      - http:
          path: e43
          method: get
          cors: true
      - http:
          path: e44
          method: get
          cors: true
      - http:
          path: e45
          method: get
          cors: true
      - http:
          path: e46
          method: get
          cors: true
      - http:
          path: e47
          method: get
          cors: true
      - http:
          path: e48
          method: get
          cors: true
      - http:
          path: e49
          method: get
          cors: true
      - http:
          path: e50
          method: get
          cors: true
      - http:
          path: e51
          method: get
          cors: true
      - http:
          path: e52
          method: get
          cors: true
      - http:
          path: e53
          method: get
          cors: true
      - http:
          path: e54
          method: get
          cors: true
      - http:
          path: e55
          method: get
          cors: true
      - http:
          path: e56
          method: get
          cors: true
      - http:
          path: e57
          method: get
          cors: true
      - http:
          path: e58
          method: get
          cors: true
      - http:
          path: e59
          method: get
          cors: true
      - http:
          path: e60
          method: get
          cors: true
      - http:
          path: e61
          method: get
          cors: true
      - http:
          path: e62
          method: get
          cors: true
      - http:
          path: e63
          method: get
          cors: true
      - http:
          path: e64
          method: get
          cors: true

• What stacktrace or error message from your provider did you see?

Template format error: Number of resources, 214, is greater than maximum allowed, 200

another possible error

Template may not exceed 460800 bytes in size.

Additional Data

• _Serverless Framework Version you're using_: 1.0.2
• _Operating System_: Windows 10 x64
• _Stack Trace_: N/A
• _Provider Error messages_: See above

Serverless Framework Version:

beta 1.0

Operating System:

windows

Additional Details:

After integrating Api getaway and lambda on Amazon console(Lambda tab) I see error lile "Could not list api-gateway event sources."

My yaml file: Functions: lambdaFunction: handler: com.myHandler.DataExtractorLambda events: - schedule: cron(0/1 * * * ? *) - http: path: publicGetaway/getResources method: get

Note: Schedule trigger is available for editing and works fine.

What did you implement:

Closes #3748

Add support for US-GovCloud and China region deployments.

How did you implement it:

Using the region information from the AWS provider, build an S3 endpoint that will work for the region.

Also removed the AccelerateConfiguration entry from the CF template since this option is not yet supported in GovCloud (not sure if it is supported in China, but excluded it from there as well).

How can we verify it:

I've tested it locally against my own GovCloud based account, but I cannot test against China regions.

Sample snippet from my serverless.yml file:

provider:
  name: aws
  runtime: python3.6
  profile: ${self:custom.profiles.${self:provider.stage}}
  region: ${self:custom.regions.${self:provider.stage}}
  stage: ${opt:stage, self:custom.defaultStage}

custom:
  regions:
    dev: us-east-1
    prod-east: us-east-1
    prod-gov: us-gov-west-1

Screenshot of successful deployment to regular US-East region:

Screenshot of successful deployment to GovCloud:

Todos:

• [x] Write tests
• [ ] Write documentation
• [x] Fix linting errors
• [x] Make sure code coverage hasn't dropped
• [x] Provide verification config / commands / resources
• [x] Enable "Allow edits from maintainers" for this PR
• [x] Update the messages below

Is this ready for review?: YES Is it a breaking change?: NO

Is there an existing issue for this?

• [X] I have searched existing issues, it hasn't been reported yet

Use case description

When snapStart:true is turned on for a function, the "snapstart" alias is used when calling the lambda from the events "http", "stream" and "sqs" but the $LATEST version is used for "websocket" (and the associated authorizer) and "scheduled" events so the SnapStart feature isn't used. There may be other unsupported events but these are the ones I have noticed.

I can work around this by overriding the CloudFormation in resources/extensions but it seems like it should be supported natively.

Proposed solution (optional)

When using snapStart:true on a function, all events attached to that function should invoke the "snapstart" alias.

Are you certain it's a bug?

• [X] Yes, it looks like a bug

Is the issue caused by a plugin?

• [X] It is not a plugin issue

Are you using the latest v3 release?

• [X] Yes, I'm using the latest v3 release

Is there an existing issue for this?

• [X] I have searched existing issues, it hasn't been reported yet

Issue description

I'm getting Couldn't find valid bootstrap(s): [/var/task/bootstrap /opt/bootstrap] error when using provided.al2. How do I configure the functions exactly?

Service configuration (serverless.yml) content

service: example

frameworkVersion: '3'

provider:
  name: aws
  runtime: provided.al2
  memorySize: 128
  stage: ${opt:stage, 'dev'}
  region: ${opt:region, 'us-west-2'}

package:
  patterns:
    - '!./**'
  individually: true

functions:
  exampleFunction1:
    handler: bin/functions/exampleFunction1
    package:
      patterns:
        - './bin/functions/exampleFunction1'

Command name and used flags

N/A

Command output

N/A

Environment information

Framework Core: 3.25.1
Plugin: 6.2.2
SDK: 4.3.2

Are you certain it's a bug?

• [X] Yes, it looks like a bug

Is the issue caused by a plugin?

• [X] It is not a plugin issue

Are you using the latest v3 release?

• [X] Yes, I'm using the latest v3 release

Is there an existing issue for this?

• [X] I have searched existing issues, it hasn't been reported yet

Issue description

Every 5 or so deploys, I get this error:

Deploying lambdas to stage dev (ap-northeast-1, "default" provider)
Compiling to node16 bundle with esbuild...
Compiling with concurrency: Infinity
Compiling completed.
Zip function: prompt-next-process - 1.11 MB [121 ms]
Zip function: prompt-scheduled-process - 1.11 MB [122 ms]
Uploading CloudFormation file to S3
Uploading State file to S3
Uploading service prompt-next-process.zip file to S3 (1.36 MB)
Uploading service prompt-scheduled-process.zip file to S3 (1.36 MB)
Creating new change set
× Stack lambdas-dev failed to deploy (11s)
Publishing service to the Serverless Dashboard...
Successfully published your service to the Serverless Dashboard: https://app.serverless.com/adamgoldman/apps/lambdas/lambdas/dev/ap-northeast-1
Environment: linux, node 18.7.0, framework 3.26.0 (local), plugin 6.2.2, SDK 4.3.2
Credentials: Serverless Dashboard, "default" provider (https://app.serverless.com/adamgoldman/apps/lambdas/lambdas/dev/ap-northeast-1/providers)
Docs:        docs.serverless.com
Support:     forum.serverless.com
Bugs:        github.com/serverless/serverless/issues
Error:
ChangeSet lambdas-dev-change-set cannot be created due to a mismatch with existing attribute Template

Service configuration (serverless.yml) content

functions:
  prompt-next-process:
    handler: handler.promptNextProcess
  prompt-scheduled-process:
    handler: handler.promptScheduledProcess

org: adamgoldman
app: lambdas
service: lambdas
frameworkVersion: "3"
useDotenv: true

provider:
  name: aws
  region: ap-northeast-1
  runtime: nodejs16.x
  environment:
    RESPOND_API_TOKEN: ${param:RESPOND_API_TOKEN}
    MONGODB_URI: ${param:MONGODB_URI}
    NODE_ENV: ${param:NODE_ENV}

plugins:
  - serverless-esbuild
  - serverless-offline

package:
  individually: true
  excludeDevDependencies: true

### Command name and used flags

NODE_ENV=development sls deploy --verbose --stage=dev

### Command output

```shell
See "issue description"

Environment information

$ serverless --version
Running "serverless" from node_modules
Framework Core: 3.26.0 (local) 3.26.0 (global)
Plugin: 6.2.2
SDK: 4.3.2

Are you certain it's a bug?

• [x] Yes, it looks like a bug

Is the issue caused by a plugin?

• [X] It is not a plugin issue

Are you using the latest v3 release?

• [X] Yes, I'm using the latest v3 release

Is there an existing issue for this?

• [X] I have searched existing issues, it hasn't been reported yet

Issue description

I tried to use per-stage-profile for deploying my application to aws (according to the documentation), but it is not using the credentials of that profile.

I used this command for settting the credentials: serverless config credentials --provider aws --key $MY_KEY --secret $MY_SECRET --profile tstProfile and used this command for deploying: serverless deploy --stage tst --verbose and this is a part of my serverless.ts configuration:

  provider: {
    name: 'aws',
    runtime: 'nodejs14.x',
    region: 'eu-west-1',
    stage: "${opt:stage}",
    profile: "${self:custom.profiles.${sls:stage}}",
    ...
  },
  custom: {
    profiles: {
      tst: 'tstProfile',
    }
  },

with this configuration, it did not use $MY_KEY and $MY_SECRET for aws and showed an error to Check your AWS Secret Access Key and signing method.

I tried to use aws-profile argument in the deploy command and it worked, but it does not work when the profile is set up inside the configuration file like the above configuration.

Service configuration (serverless.yml) content

import type { AWS } from '@serverless/typescript';

import hello from '@functions/hello';

const serverlessConfiguration: AWS = {
  service: 'reusable-container-id-generator',
  frameworkVersion: '3',
  plugins: ['serverless-esbuild', 'serverless-offline'],
  provider: {
    name: 'aws',
    runtime: 'nodejs14.x',
    region: 'eu-west-1',
    stage: "${opt:stage}",
    stackName: 'reusable-container-id-generator',
    // deploymentInformation
    profile: "${self:custom.profiles.${sls:stage}}",
    apiGateway: {
      minimumCompressionSize: 1024,
      shouldStartNameWithService: true,
    },
    environment: {
      AWS_NODEJS_CONNECTION_REUSE_ENABLED: '1',
      NODE_OPTIONS: '--enable-source-maps --stack-trace-limit=1000',
    },
  },
  // import the function via paths
  functions: { hello },
  package: { individually: true },
  custom: {
    esbuild: {
      bundle: true,
      minify: false,
      sourcemap: true,
      exclude: ['aws-sdk'],
      target: 'node14',
      define: { 'require.resolve': undefined },
      platform: 'node',
      concurrency: 10,
    },
    profiles: {
      tst: 'tstProfile',
    }
  },
};

module.exports = serverlessConfiguration;

Command name and used flags

serverless deploy --stage tst --verbose

Command output

The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

Environment information

Running "serverless" from node_modules
Framework Core: 3.26.0 (local) 3.26.0 (global)
Plugin: 6.2.2
SDK: 4.3.2

Is there an existing issue for this?

• [X] I have searched existing issues, it hasn't been reported yet

Use case description

Currently the iot event only supports an Action for a topic rule. I want to be able to define an error action (https://docs.aws.amazon.com/iot/latest/developerguide/rule-error-handling.html).

Proposed solution (optional)

Provided the YML:

  myFunction:
    handler: ...
    events:
      - iot:
          sql: "SELECT * FROM 'test_unit'"
          errorAction: <ref a function arn here> 

The appropriate CF templating will be performed (see reference in description)

Are you certain it's a bug?

• [X] Yes, it looks like a bug

Is the issue caused by a plugin?

• [X] It is not a plugin issue

Are you using the latest v3 release?

• [X] Yes, I'm using the latest v3 release

Is there an existing issue for this?

• [X] I have searched existing issues, it hasn't been reported yet

Issue description

I started the API gateway locally through the command "serverless offline". It exposed all the endpoints when I hit them. I got the following error : Error: DataCloneError: async (event_, context = {}) => { const event = cleanUpEvent(event_, options);

const request = createR...<omitted>... } could not be cloned.
at MessagePort.<anonymous> (file:///C:/Users/prati/Desktop/City%20University%20of%20London/Cloud%20Computing/second_trial/recipe/node_modules/serverless-offline/src/lambda/handler-runner/worker-thread-runner/workerThreadHelper.js:30:8)

How do you think I should handle this error?

Service configuration (serverless.yml) content

service: recipe
frameworkVersion: '3'

provider:
  name: aws
  runtime: nodejs14.x
  iam:
    role:
      statements:
        - Effect: 'Allow'
          Action:
            - "lambda:InvokeFunction"
            - "lambda:InvokeAsync"
          Resource: "*"

functions:
  main:
    handler: main.handler
    name: main
    events:
      - http:
          path: /healthCheck
          method: get
      - http:
          path: /setWebhook
          method: get
      - http:
          path: /botMessage
          method: post
  getAPIResultStoreInDatabase:
    handler: fetch-api-response.handler
    name: getAPIResultStoreInDatabase
    environment:
      TABLE_NAME: recipeTable

plugins:
  - serverless-offline

resources:
  Resources:
    MyTable:
      Type: AWS::DynamoDB::Table
      Properties:
        AttributeDefinitions:
          - AttributeName: recipeName
            AttributeType: S
        KeySchema:
          - AttributeName: recipeName
            KeyType: HASH
        ProvisionedThroughput:
          ReadCapacityUnits: 1
          WriteCapacityUnits: 1
        TableName: recipeTable

Command name and used flags

serverless offline

Command output

Error:
DataCloneError: async (event_, context = {}) => {
    const event = cleanUpEvent(event_, options);

    const request = createR...<omitted>... } could not be cloned.
    at MessagePort.<anonymous> (file:///C:/Users/prati/Desktop/City%20University%20of%20London/Cloud%20Computing/second_trial/recipe/node_modules/serverless-offline/src/lambda/handler-runner/worker-thread-runner/workerThreadHelper.js:30:8)

Environment information

Framework Core: 3.25.1
Plugin: 6.2.2
SDK: 4.3.2