serverless-offline 14.7.2 → 14.7.4

package/README.md

@@ -155,7 +155,7 @@ Default: localhost
 
 #### dockerHostServicePath
 
-Defines service path which is used by SLS running inside Docker container.
+Defines the service path used by SLS running inside a Docker container.
 
 #### dockerNetwork
 
@@ -284,14 +284,14 @@ By default you can send your requests to `http://localhost:3000/`. Please note t
 
 - You'll need to restart the plugin if you modify your `serverless.yml` or any of the default velocity template files.
 - When no Content-Type header is set on a request, API Gateway defaults to `application/json`, and so does the plugin.
-  But if you send an `application/x-www-form-urlencoded` or a `multipart/form-data` body with an `application/json` (or no) Content-Type, API Gateway won't parse your data (you'll get the ugly raw as input), whereas the plugin will answer 400 (malformed JSON).
+  But if you send an `application/x-www-form-urlencoded` or a `multipart/form-data` body with an `application/json` (or no) Content-Type, API Gateway won't parse your data (you'll get the ugly raw data as input), whereas the plugin will answer 400 (malformed JSON).
   Please consider explicitly setting your requests' Content-Type and using separate templates.
 
 ## Run modes
 
 ### node.js
 
-Lambda handlers with `serverless-offline` for the `node.js` runtime can run in different execution modes and have some differences with a variety of pros and cons. They are currently mutually exclusive and it's not possible to use a combination, e.g. use `in-process` for one Lambda, and `worker-threads` for another. It is planned to combine the flags into one single flag in the future and also add support for combining run modes.
+Lambda handlers with `serverless-offline` for the `node.js` runtime can run in different execution modes, each with its own pros and cons. They are currently mutually exclusive and it's not possible to use a combination, e.g. use `in-process` for one Lambda, and `worker-threads` for another. It is planned to combine the flags into one single flag in the future and also add support for combining run modes.
 
 #### worker-threads (default)
 
@@ -466,7 +466,7 @@ If you're using least-privilege principals for your AWS roles, this policy shoul
 }
 ```
 
-Once you run a function that boots up the Docker container, it'll look through the layers for that function, download them in order to your layers folder, and save a hash of your layers so it can be re-used in the future. You'll only need to re-download your layers if they change in the future. If you want your layers to re-download, simply remove your layers folder.
+Once you run a function that boots up the Docker container, it'll look through the layers for that function, download them to your layers folder, and save a hash of your layers so it can be re-used in the future. You'll only need to re-download your layers if they change in the future. If you want your layers to re-download, simply remove your layers folder.
 
 You should then be able to invoke functions as normal, and they're executed against the layers in your docker container.
 
@@ -490,11 +490,11 @@ When running Docker Lambda inside another Docker container, you may need to over
 
 #### dockerNetwork
 
-When running Docker Lambda inside another Docker container, you may need to override network that Docker Lambda connects to in order to communicate with other containers.
+When running Docker Lambda inside another Docker container, you may need to override the network that Docker Lambda connects to in order to communicate with other containers.
 
 #### dockerReadOnly
 
-For certain programming languages and frameworks, it's desirable to be able to write to the filesystem for things like testing with local SQLite databases, or other testing-only modifications. For this, you can set `dockerReadOnly: false`, and this will allow local filesystem modifications. This does not strictly mimic AWS Lambda, as Lambda has a Read-Only filesystem, so this should be used as a last resort.
+For certain programming languages and frameworks, it's desirable to be able to write to the filesystem for things like testing with local SQLite databases, or other testing-only modifications. For this, you can set `dockerReadOnly: false`, and this will allow local filesystem modifications. This does not strictly mimic AWS Lambda, as Lambda has a read-only filesystem, so this should be used as a last resort.
 
 #### layersDir
 
@@ -506,7 +506,7 @@ By default layers are downloaded on a per-project basis, however, if you want to
 
 As defined in the [Serverless Documentation](https://serverless.com/framework/docs/providers/aws/events/apigateway/#setting-api-keys-for-your-rest-api) you can use API Keys as a simple authentication method.
 
-Serverless-offline will emulate the behaviour of APIG and create a random token that's printed on the screen. With this token you can access your private methods adding `x-api-key: generatedToken` to your request header. All api keys will share the same token.
+Serverless-offline will emulate the behaviour of APIG and create a random token that's printed on the screen. With this token you can access your private methods by adding `x-api-key: generatedToken` to your request header. All API keys will share the same token.
 
 ### Custom authorizers
 
@@ -524,7 +524,7 @@ The Custom authorizer is passed an `event` object as below:
 
 The `methodArn` does not include the Account id or API id.
 
-The plugin only supports retrieving Tokens from headers. You can configure the header as below:
+The plugin only supports retrieving tokens from headers. You can configure the header as below:
 
 ```js
 "authorizer": {
@@ -775,7 +775,7 @@ There's support for [websocketsApiRouteSelectionExpression](https://docs.aws.ama
 
 ## Debug process
 
-The Serverless offline plugin will respond to the overall framework settings and output additional information to the console in debug mode. In order to do this you will have to set the `SLS_DEBUG` environmental variable. You can run the following in the command line to switch to debug mode execution.
+The Serverless offline plugin will respond to the overall framework settings and output additional information to the console in debug mode. In order to do this you will have to set the `SLS_DEBUG` environment variable. You can run the following in the command line to switch to debug mode execution.
 
 > Unix: `export SLS_DEBUG=*`
 
@@ -789,9 +789,9 @@ Initial installation:
 For each debug run:
 `node-debug sls offline`
 
-The system will start in wait status. This will also automatically start the chrome browser and wait for you to set breakpoints for inspection. Set the breakpoints as needed and, then, click the play button for the debugging to continue.
+The system will start in wait status. This will also automatically start the Chrome browser and wait for you to set breakpoints for inspection. Set the breakpoints as needed and, then, click the play button for the debugging to continue.
 
-Depending on the breakpoint, you may need to call the URL path for your function in separate browser window for your serverless function to be run and made available for debugging.
+Depending on the breakpoint, you may need to call the URL path for your function in a separate browser window for your serverless function to be run and made available for debugging.
 
 ### Interactive Debugging with Visual Studio Code (VSC)
 
@@ -832,7 +832,7 @@ Example:
 }
 ```
 
-In VSC, you can, then, add breakpoints to your code. To start a debug session you can either start your script in `package.json` by clicking the hovering debug intellisense icon or by going to your debug pane and selecting the Debug Serverless Offline configuration.
+In VSC, you can then add breakpoints to your code. To start a debug session you can either start your script in `package.json` by clicking the hovering debug IntelliSense icon or by going to your debug pane and selecting the Debug Serverless Offline configuration.
 
 ## Resource permissions and AWS profile
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "serverless-offline",
-  "version": "14.7.2",
+  "version": "14.7.4",
   "description": "Emulate AWS λ and API Gateway locally when developing your Serverless project",
   "license": "MIT",
   "exports": {
@@ -58,7 +58,7 @@
     "hideCredit": true
   },
   "dependencies": {
-    "@aws-sdk/client-lambda": "^3.1052.0",
+    "@aws-sdk/client-lambda": "^3.1069.0",
     "@hapi/boom": "^10.0.1",
     "@hapi/h2o2": "^10.0.4",
     "@hapi/hapi": "^21.4.9",
@@ -80,24 +80,24 @@
     "node-schedule": "^2.1.1",
     "p-memoize": "^7.1.1",
     "tree-kill": "^1.2.2",
-    "tsx": "^4.22.3",
+    "tsx": "^4.22.4",
     "velocityjs": "^2.1.6",
     "ws": "^8.21.0"
   },
   "devDependencies": {
     "@istanbuljs/esm-loader-hook": "^0.3.0",
     "archiver": "^7.0.1",
-    "auto-changelog": "^2.5.1",
+    "auto-changelog": "^2.6.0",
     "eslint": "^8.57.0",
     "eslint-config-airbnb-base": "^15.0.0",
     "eslint-config-prettier": "^9.1.0",
     "eslint-plugin-import": "^2.32.0",
-    "eslint-plugin-prettier": "^5.5.5",
+    "eslint-plugin-prettier": "^5.5.6",
     "eslint-plugin-unicorn": "^54.0.0",
     "mocha": "^11.7.6",
     "nyc": "^17.0.0",
-    "prettier": "^3.8.3",
-    "serverless": "^4.36.1"
+    "prettier": "^3.8.4",
+    "serverless": "^4.37.0"
   },
   "peerDependencies": {
     "serverless": "^4.0.0"

package/src/config/supportedRuntimes.js

@@ -25,6 +25,7 @@ export const supportedRuntimesArchitecture = {
   "ruby3.2": [ARM64, X86_64],
   "ruby3.3": [ARM64, X86_64],
   "ruby3.4": [ARM64, X86_64],
+  "ruby4.0": [ARM64, X86_64],
   java8: [X86_64],
   "java8.al2": [ARM64, X86_64],
   java11: [ARM64, X86_64],
@@ -74,6 +75,7 @@ export const supportedRuby = new Set([
   "ruby3.2",
   "ruby3.3",
   "ruby3.4",
+  "ruby4.0",
 ])
 
 export const supportedRuntimes = new Set([

package/src/events/alb/HttpServer.js

@@ -168,7 +168,7 @@ export default class HttpServer {
     return async (request, h) => {
       const requestPath = this.#options.noPrependStageInUrl
         ? request.path
-        : request.path.substr(`/${stage}`.length)
+        : request.path.slice(`/${stage}`.length)
 
       // Payload processing
       const encoding = detectEncoding(request)

package/src/events/http/HttpServer.js

@@ -451,7 +451,7 @@ export default class HttpServer {
       const requestPath =
         endpoint.isHttpApi || this.#options.noPrependStageInUrl
           ? request.path
-          : request.path.substr(`/${stage}`.length)
+          : request.path.slice(`/${stage}`.length)
 
       // payload processing
       const encoding = detectEncoding(request)
@@ -537,14 +537,9 @@ export default class HttpServer {
 
       if (
         contentTypesThatRequirePayloadParsing.includes(contentType) &&
-        request.payload &&
-        request.payload.length > 1
+        request.payload
       ) {
         try {
-          if (!request.payload || request.payload.length === 0) {
-            request.payload = "{}"
-          }
-
           request.payload = parse(request.payload)
         } catch (err) {
           log.debug("error in converting request.payload to JSON:", err)

package/src/events/websocket/WebSocketClients.js

@@ -273,17 +273,8 @@ export default class WebSocketClients {
       log.debug(`Error in route handler '${route.functionKey}'`, err)
     }
 
-    const authorizerData = this.#webSocketAuthorizersCache.get(connectionId)
-    let authorizedEvent
-
-    if (authorizerData) {
-      authorizedEvent = event
-      authorizedEvent.requestContext.identity = authorizerData.identity
-      authorizedEvent.requestContext.authorizer = authorizerData.authorizer
-    }
-
     const lambdaFunction = this.#lambda.get(route.functionKey)
-    lambdaFunction.setEvent(authorizedEvent || event)
+    lambdaFunction.setEvent(event)
 
     try {
       const { body } = await lambdaFunction.runHandler()

package/src/lambda/handler-runner/HandlerRunner.js

@@ -98,9 +98,19 @@ export default class HandlerRunner {
   }
 
   // () => Promise<void>
-  cleanup() {
+  async cleanup() {
     // TODO console.log('handler runner cleanup')
-    return this.#runner.cleanup()
+    const runner = this.#runner
+
+    // drop the reference so the next run() lazily recreates a fresh runner.
+    // this is essential after a timeout: the worker thread is terminated by
+    // cleanup() but the (now dead) runner would otherwise be reused, wedging
+    // every subsequent invocation. see https://github.com/dherault/serverless-offline/issues/1896
+    this.#runner = null
+
+    if (runner != null) {
+      await runner.cleanup()
+    }
   }
 
   async run(event, context) {

package/src/lambda/handler-runner/python-runner/PythonRunner.js

@@ -8,7 +8,7 @@ import { log } from "../../../utils/log.js"
 import { splitHandlerPathAndName } from "../../../utils/index.js"
 
 const { parse, stringify } = JSON
-const { assign, hasOwn } = Object
+const { hasOwn } = Object
 
 export default class PythonRunner {
   static #payloadIdentifier = "__offline_payload__"
@@ -47,7 +47,7 @@ export default class PythonRunner {
         handlerName,
       ],
       {
-        env: assign(process.env, this.#env),
+        env: { ...process.env, ...this.#env },
         shell: true,
       },
     )

package/src/lambda/handler-runner/worker-thread-runner/workerThreadHelper.js

@@ -24,6 +24,7 @@ parentPort.on("message", async (messageData) => {
     result = await inProcessRunner.run(event, context)
   } catch (err) {
     port.postMessage(err)
+    return
   }
 
   // TODO check serializeability (contains function, symbol etc)