InvalidParameterValueException: Unzipped size must be smaller than 262144000 bytes with artillery lambda

[saurabhmarwaha]

Same bug reported in #2337 is still occurring in latest version Artillery v2.0.8
\\-->

Same bug reported in #2337 is still occurring in latest version Artillery v2.0.8

Version info:

 Artillery v2.0.8
Node.js:   v20.11.1
OS:        win32

Running this command:

artillery run-lambda backend-api.yml

I expected to see this happen:

explanation

Instead, this happened:

Test run id: tjw3m_x3arb3e5c5knp8faheyk3345c7fzg_gzh9
NOTE: AWS Lambda support is experimental. Not all Artillery features work yet.
For details please see https://docs.art/aws-lambda

λ Creating AWS Lambda function...
- Bundling test data
  - backend-api.yml
  - package.json
  - package-lock.json
- Installing dependencies
- Installing extra engines & plugins: artillery
- Creating zip package
Preparing AWS environment...
- C:\Users\<<user>>\AppData\Roaming\npm\node_modules\artillery\node_modules\aws-sdk\lib\protocol\json.js:80
  resp.error = util.error(new Error(), error);
                          ^

**InvalidParameterValueException: Unzipped size must be smaller than 262144000 bytes**
---
---
---
  code: '**InvalidParameterValueException**',
  '[Type]': 'See error.Type for details.',
  time: 2024-03-21T07:16:20.644Z,
  requestId: '95305fe6-826c-4d25-9645-8b8ff8541946',
  statusCode: 400,
  retryable: false,
  retryDelay: 90.7009000570459
}
Node.js v20.11.1

Files being used:

config:
  # This is a test server run by team Artillery
  # It's designed to be highly scalable
  target: https://domain.com
  phases:
    - duration: 60
      arrivalRate: 1
      rampTo: 5
      name: Warm up phase
  # Load & configure a couple of useful plugins
  # https://docs.art/reference/extensions
  plugins:
    ensure: {}
    apdex: {}
    metrics-by-endpoint: {}
  apdex:
    threshold: 100
  ensure:
      thresholds:
        - http.response_time.p99: 100
        - http.response_time.p95: 75
scenarios:
  - flow:
      - loop:
        - get:
            url: "/"
        count: 100

[bernardobridge]

Hey @saurabhmarwaha 👋

This issue is likely happening due to keeping your package.json in the same folder as the scenario YAML, while including artillery as a direct dependency - this is one of the reasons why we don't recommend installing Artillery as a dependency.

To fix it, do one of the following:

• Don't include Artillery as a dependency
• OR Change your test folder hierarchy so that the scenario you're trying to run isn't at the same level as a package.json that contains Artillery as a dependency

Let me know if that works 🙇 !

[saurabhmarwaha]

@bernardobridge

Thank you. I tried and still getting the same error where I opted in to change folder hierarchy so that the scenario I am trying to run isn't at the same level as a package.json

See Folder Structure and error

Steps followed:

1. Created a new folder loadtest1
2. npm install artillery@latest under loadtest1
3. loadtest1/scenario/backend-endpoint-matrix.yml

scenarios:
  - name: armadillo
    flow:
      - get:
          url: "/armadillo"
          expect:
            statusCode: 200

4 loadtest1\common-config.yml

config:
  target: http://asciizoo.artillery.io:8080
  plugins:
    metrics-by-endpoint: {}
    expect: {}

[bernardobridge]

@saurabhmarwaha Can you try to change the common-config.yml as well? Something like:

scenarios|backend-endpoint-matrix.yml
configs|common.config.yml

Should probably work to prevent it from picking up the package.json. Alternatively, just don't install Artillery as a dependency of the repo.

We'll improve this setup soon though. Let me know how it works for you!

[saurabhmarwaha]

@bernardobridge - Same error.

My ideal use case is to separate multiple scenarios pointing to same config as config doesn't change.

I am actually testing Separating scenarios into separate files example from artilleryio which is not working

[bernardobridge]

Thanks @saurabhmarwaha . I can't reproduce it on my side, so there's a chance this is only happening in Windows machines. I'll have to try to replicate it on one when I have a chance.

---

In the meantime, if this is blocking you, have you tried using our AWS Fargate support? It's more robust, and usually equally easy to set up, so you should hopefully not run into the same issues.