awslabs / llrt Goto Github PK

Similar request to #149 but for AWS CDK

in Node.js both of these imports are valid and work:

import EventEmitter from 'events'
import { EventEmitter } from 'events'

const a = new EventEmitter()

however in llrt (0.1.5-beta) the former fails:

// llrt-test.mjs
import EventEmitter from 'events'

const a = new EventEmitter()

$ ./llrt llrt-test.mjs
TypeError: not a constructor
    at <anonymous> (llrt-test.mjs:3:11)

Currently LLRT has no support for the HTTP and HTTPS modules from node.js.

The only way to do http calls is to rely on the fetch call.

LLRT should support HTTP and HTTPS modules with a select set of features:

https://nodejs.org/api/http.html
https://nodejs.org/api/https.html

Advanced TLS capabilities should be omitted like custom certificate handling.

Size: Large

U.

Is there a plan to support reading from stdin and writing to stdout? For instance in BunJS, I can do streaming:

for await (let chunk of Bun.stdin.stream()) {}

const writer = Bun.stdout.writer();

I'm hitting the following error on the compile step for ring:

warning: [email protected]: error: unable to parse target query 'aarch64-unknown-linux-musl': UnknownOperatingSystem
warning: [email protected]: ToolExecError: Command "/home/moderation/Library/llrt/linker/cc-aarch64-linux-musl" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=aarch64-unknown-linux-musl" "-I" "include" "-I" "/home/moderation/Library/llrt/target/aarch64-unknown-linux-musl/release/build/ring-27e1b34e3efd1c61/out" "-Wall" "-Wextra" "-fvisibility=hidden" "-std=c1x" "-Wall" "-Wbad-function-cast" "-Wcast-align" "-Wcast-qual" "-Wconversion" "-Wmissing-field-initializers" "-Wmissing-include-dirs" "-Wnested-externs" "-Wredundant-decls" "-Wshadow" "-Wsign-compare" "-Wsign-conversion" "-Wstrict-prototypes" "-Wundef" "-Wuninitialized" "-g3" "-nostdlibinc" "-DNDEBUG" "-DRING_CORE_NOSTDLIBINC=1" "-o" "/home/moderation/Library/llrt/target/aarch64-unknown-linux-musl/release/build/ring-27e1b34e3efd1c61/out/fad98b632b8ce3cc-curve25519.o" "-c" "crypto/curve25519/curve25519.c" with args "cc-aarch64-linux-musl" did not execute successfully (status code exit status: 1).running: "/home/moderation/Library/llrt/linker/cc-aarch64-linux-musl" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=aarch64-unknown-linux-musl" "-I" "include" "-I" "/home/moderation/Library/llrt/target/aarch64-unknown-linux-musl/release/build/ring-27e1b34e3efd1c61/out" "-Wall" "-Wextra" "-fvisibility=hidden" "-std=c1x" "-Wall" "-Wbad-function-cast" "-Wcast-align" "-Wcast-qual" "-Wconversion" "-Wmissing-field-initializers" "-Wmissing-include-dirs" "-Wnested-externs" "-Wredundant-decls" "-Wshadow" "-Wsign-compare" "-Wsign-conversion" "-Wstrict-prototypes" "-Wundef" "-Wuninitialized" "-g3" "-nostdlibinc" "-DNDEBUG" "-DRING_CORE_NOSTDLIBINC=1" "-o" "/home/moderation/Library/llrt/target/aarch64-unknown-linux-musl/release/build/ring-27e1b34e3efd1c61/out/ca4b6ef5433f5aeb-aes_nohw.o" "-c" "crypto/fipsmodule/aes/aes_nohw.c"

I think the error is related to briansmith/ring#563 (comment) however none of the work arounds are helping.

Not sure if related but downloading the latest release binary for Linux `aarch64 results in a crash:

llrt --version
fish: Job 1, 'llrt --version' terminated by signal SIGILL (Illegal instruction)

Hyper 1.0 now features a lower level API that requires a handling of handshakes, tcp-connections and reading data from frames.

LLRT should use this lower level API to be able to support behaviour similar to http and https modules from node.

Switching to a lower level API also enables switch to AWS-LibCrypto to improve TLS handshake time.

The downside would be that we now need to implement a connection pool since that was previously handled by hyper.

However, we can reuse this connection pool from both fetch, http/https and raw sockets for better performance. This is not possible in the current implementation.

References:
https://docs.rs/aws-lc-rs - AWS LibCrypto
https://docs.rs/deadpool/0.10.0/deadpool/ - General Purpose Connection Pool

Say we have the following code:

// index.mjs
import { randomBytes } from "crypto";
console.log(randomBytes(10).toString("base64"));
console.log(randomBytes(10));

It does not return the same result (aside from randomness) as Node.js

node index.mjs
# base64 string
3HJqTvKlThpveA==
<Buffer ff 68 8c 61 7d 57 32 8b 00 36>


llrt index.mjs
# just an array
199,143,52,135,209,139,167,219,9,14
Uint8Array [ 169, 68, 55, 29, 169, 125, 37, 213, 114, 125 ]

It seems the returned type from randomBytes is different between llrt and node.

Hi, we have received a report from a customer that LLRT is not compatible with Powertools for AWS Lambda (TypeScript) (aws-powertools/powertools-lambda-typescript#2050.

From an initial test we were able to narrow down the issue to the usage of the console module. Below a code snippet that results in an exception:

import { Console } from "node:console";

const con = new Console({ stdout: process.stdout, stderr: process.stderr });

export const handler = async (event: any) => {
  con.log("Hello, world!");
  return "Hello, world!";
};

Full error below:

  24-02-12T15:15:47.833Z        n/a     ERROR   ReferenceError: Error resolving module 'console' from '/var/task/index.mjs'
} stackTrace: [ '' ]or resolving module 'console' from '/var/task/index.mjs'',
INIT_REPORT Init Duration: 40.23 ms     Phase: init     Status: error   Error Type: Runtime.ExitError
  24-02-12T15:15:48.350Z        n/a     ERROR   ReferenceError: Error resolving module 'console' from '/var/task/index.mjs'
} stackTrace: [ '' ]or resolving module 'console' from '/var/task/index.mjs'',
INIT_REPORT Init Duration: 523.69 ms    Phase: invoke   Status: error   Error Type: Runtime.ExitError
START RequestId: 36e99bfc-806a-4326-963b-354ee212c545 Version: $LATEST
END RequestId: 36e99bfc-806a-4326-963b-354ee212c545
REPORT RequestId: 36e99bfc-806a-4326-963b-354ee212c545  Duration: 551.40 ms     Billed Duration: 551 ms Memory Size: 128 MB     Max Memory Used: 21 MB  Status: error      Error Type: Runtime.ExitError

The console module is listed as supported in the compatibility matrix in your readme but doesn't appear in the API docs document.

Any chance that you could confirm whether the module is expected to work? If not, we'd like to raise a feature request for it to be eventually implemented on behalf of this customer.

Hi, I found In the current README, there are seemingly contradicting descriptions about bundling:

All dependencies should be bundled for a browser platform

esbuild index.js --platform=node --target=es2020 --format=esm --bundle --minify --external:@AWS-SDK --external:@smithy --external:uuid

so which --platform option (node or browser) should we set when using esbuild?

We are using Sentry via a lambda layer in our application. See here. Layer arn: arn:aws:lambda:eu-central-1:943013980633:layer:SentryNodeServerlessSDK:193

The @sentry/serverless package is imported in our app like this:
import { AWSLambda } from '@sentry/serverless'; / var import_serverless = require("@sentry/serverless"); (after esbuild)

In our cdk build step, we exclude it via external modules:

externalModules: ['@sentry/serverless', ...]

but with LLRT, we get the following error when the lambda function is invoked:

ERROR	{
  errorType: 'ReferenceError',
  errorMessage: 'Error resolving module '@sentry/serverless' from '/var/task/index.mjs'',
  stackTrace: [ '' ]
}

If I remove @sentry/serverless from externalModules, the error disappears, so I guess either the layer is not getting picked up by LLRT.

Since all fs methods are async in LLRT implementing callbacks for fs is trivial. They could be wrapped in a "callbackify" utility that will await the future and call a function with cb(err,result) rather than awaiting the result.

Size

S

I wanted to try LLRT via https://github.com/tmokmss/cdk-lambda-llrt, but the lambda execution fails on initialization, as a library we use (pg-promise) relies on process.versions.node to be set.

In LLRT process.version is set, but process.versions is not (see nodejs docs).

I can see that llrt would not return process.versions.node with a valid nodejs version number (since it is not a nodejs version), but LLRT should probably return some kind of object for process.versions at least, right?

Thanks for your work!

Currently I use esbuild to build the main.js file, however it seems the url module is not supported and an error appears as below. Please help.

Response
{
"errorType": "ReferenceError",
"errorMessage": "Error resolving module 'url' from '/var/task/dist/main.js'",
"stackTrace": [
""
]
}

Sourcemaps are currently not supported meaning that stack traces will be from transpiled JS sources. This is not ideal for debugging purposes.

The parcel bundler has implemented support for source maps in a rust package. Its not available on crates.io but the logic of deserializing a sourcemap is not very complicated.

https://github.com/parcel-bundler/source-map/tree/master/parcel_sourcemap

Here is explanation of sourcemaps:
https://www.bugsnag.com/blog/source-maps/

If this could be implemented without pulling in serde json dependency it would be ideal since the QuickJS engine already has a build in json parser

https://wintercg.org/

Many cloud providers and other groups in the industry are aligning on standards for new non-node based runtimes.

Will llrt attempt to follow specifications created by the WinterCG?

Library authors are starting to need to consider differences between many Javascript runtimes, aligning on standards for these new runtimes will help ensure consistency and compatibility.

Description

Started implementing basic support for sockets but this was removed due to a major version upgrade of the QuickJS binding layer.

Since then spawn from child_process have been implemented and is using a native readable/writable stream for reading from stdin, stderr and stdout. This readable/writable stream could be used for sockets as well as it uses the same interface for communication (event emitter)

Size

L

Expressing the Node.js compatibility matrix and API guide as typescript .d.ts files would let users statically check that they are only using supported features, and provide inline IDE documentation.

Users could rely on @types/node but would have to guess at the target version (is it 20, 18, 22?) and remember which APIs aren't supported or rely on tests.

I note that hermes isn't mentioned in your "why not an existing solution" section. It'd be great to have an analysis of that one, since its goals seem much more aligned with LLRT's.

In LLRT, Headers.forEach is not implemented.

llrt  -e "console.log(new Headers().forEach)"  
undefined

node  -e "console.log(new Headers().forEach)"
[Function: forEach]

I think this is a final missing piece to run Hono hello world on LLRT.

It's mainly the node build script that is relying on unix paths at the moment. Path.join is platform specific (which is strange since windows supports forward slashes since forever)

This was working in either 0.1.6 or 0.1.7, but with 0.1.8 this code

        const command = new GetObjectCommand({
                Bucket: BUCKET,
                Key: "index.html",
            })
        const response = await s3.send(command);
        console.log({
            response,
            bodyString: await response.Body.transformToString(),
            bodyArray: await response.Body.transformToByteArray()
        })

logs

{
  response: {
    $metadata: { httpStatusCode: 200, ..., cfId: undefined, attempts: 1, totalRetryDelay: 0 },
    AcceptRanges: 'bytes',
    LastModified: 2024-02-21T15:09:47.000Z,
    ContentLength: 582,
    ...
    CacheControl: 'no-cache,max-age=0,public',
    ContentType: 'text/html',
    ServerSideEncryption: 'AES256',
    Metadata: {},
    Body: { transformToByteArray: [function: Me], transformToString: [function: Re], transformToWebStream: [function: Ie] }
  },
  bodyString: '[object Object]',
  bodyArray: [Circular]
}

Seems like the transform* functions are operating on the Body object with functions, rather than on the responses actual Body.

Hello,

A perfectly Node20 Lambda can upload a file into S3
When I switch to LLRT, I cannot do it anymore.

SAM TEMPLATE:

UploadToS3:
    Type: AWS::Serverless::Function
    Properties:
      Timeout: 10
      Architectures: ["arm64"]
      MemorySize: 128
      Runtime: provided.al2
      # MemorySize: 1024
      # Runtime: nodejs20.x
      .....
   Metadata:
      BuildMethod: esbuild
      BuildProperties:
        External:
          - '@aws-sdk/client-s3'
        Minify: true
        Target: "es2020"
        Sourcemap: false
        Format: esm
        OutExtension:
          - .js=.mjs
        EntryPoints:
        - uploadToS3.ts

LAMBDA:

import { S3Client, ClientDefaults, PutObjectCommand, PutObjectCommandInput, ObjectCannedACL } from "@aws-sdk/client-s3";

const clientDefaults: ClientDefaults = {
  region: process.env.AWS_REGION,
};
const s3Client = new S3Client(clientDefaults);

export const handler = async (event) => {
  console.debug("event", JSON.stringify(event));

  try {
    const jsonFile = {
      "data": event,
    }
    const params: PutObjectCommandInput = {
      Bucket: process.env.BUCKET_NAME,
      Key: `path/${event.id}.json`,
      Body: JSON.stringify(jsonFile),
      ACL: ObjectCannedACL.bucket_owner_full_control,
      ContentType: "application/json",
    };
    const command = new PutObjectCommand(params);
    await s3Client.send(command);
  } catch (error) {
    console.error(error);
  }
};

LOG:

{
  "errorType": "TypeError",
  "errorMessage": "not a function",
  "stackTrace": [
    "    at C (/var/task/uploadToS3.mjs:1:159)",
    "    at startProcessEvents (@llrt/runtime:5:159)",
    ""
  ],
  "requestId": "c03887d1-66d8-476b-ada6-cd8e1aaadfc6"
}

{
  "time": "2023-11-25T08:34:30.527Z",
  "type": "platform.runtimeDone",
  "record": {
    "requestId": "c03887d1-66d8-476b-ada6-cd8e1aaadfc6",
    "status": "success",
    "metrics": {
      "durationMs": 2.25,
      "producedBytes": 0
    }
  }
}
{
  "time": "2023-11-25T08:34:30.529Z",
  "type": "platform.report",
  "record": {
    "requestId": "c03887d1-66d8-476b-ada6-cd8e1aaadfc6",
    "status": "success",
    "metrics": {
      "durationMs": 2.556,
      "billedDurationMs": 44,
      "memorySizeMB": 128,
      "maxMemoryUsedMB": 29,
      "initDurationMs": 40.651
    }
  }
}

I'd like to gracefully shutdown my lambda

However, looks like LLRT has no process.on('SIGTERM', ... implemented yet

In order to keep the binary size to a minimum only a subset clients of the full AWS SDK v3 is bundled currently.
Multiple binaries

We could via feature flags build multiple flavors of LLRT:

• llrt-full - The full SDK bundled
• llrt-min - No SDK bundled
• llrt - The default version (current) with the most popular packages bundled

Futhermore, we could allow customers to download the bundled and optimized SDKs as .lrt files. .lrt files is zstd compressed QuickJS bytecode that can be imported in llrt (already supported)

Size

L

I noticed that the Response object, which is strangely defined globally in the source code¹, cannot be referenced during the execution of llrt. I found this while writing a simple web server.

I can see this in the following way:

# https://github.com/awslabs/llrt/releases/download/v0.1.6-beta/llrt-darwin-arm64.zip
llrt -e 'new Request("http://localhost:3000/") && console.log("OK")'

OK

llrt -e 'new Response() && console.log("OK")'

ReferenceError: 'Response' is not defined
    at <eval> (eval_script:1:5)

basically the subject

// llrt-test.mjs
function foo() {
  return Promise.resolve(42)
}

console.log(await foo())

$ ./llrt llrt-test.mjs
SyntaxError: unexpected 'await' keyword
    at llrt-test.mjs:5:12

https://w3c.github.io/webcrypto/#dfn-SubtleCrypto
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto?retiredLocale=sv-SE

Is there some AWS::Serverless-2016-10-31 template.yaml & aws-actions/setup-sam@v2 example please?

https://github.com/awslabs/llrt?tab=readme-ov-file#configure-lambda-functions-to-use-llrt isn't straightforward enough

I found the error message is not correct in /example/functions/src/react/TodoList.tsx. I have attached the line number and screenshot as well. Instead of 'Could not create todo' error message, it should be 'Could not delete todo'.

#25

Currently Readable & Writable streams are only available from a polyfilled JavScript module and is not used inside the SDK or for Fetch calls for performance and latency reasons.

LLRT should implement Readable-, Writable-, Duplex- and Transfer streams nativly in Rust. This would allow performant stream processing, increase throughput and be more memory efficient as users can pipe data through streams.

However, the streams API is gigantic. The polyfilled streams module is almost 6500 lines of JS supporting a lot of edge cases. There is also some difference between Node.js Streams and WebStreams.

A very basic initial implementation is currently implemented for child_process and socket module that can be expanded to support a richer Streams API.

running the following

// llrt-test.mjs
console.log(require('os').release())

results in a segmentation fault:

$ ./llrt llrt-test.mjs
[1]    76305 segmentation fault  ./llrt llrt-test.mjs

LLRT (darwin arm64) 0.1.5-beta
macOS 14.2.1 on MacBook Pro (M1, 2021)

Since version v0.1.4 and onward through the current (v0.1.7) release, JSON serialization of objects that include a Date property result in improperly formatted JSON, with duplicate rendering of keys.

Using v0.1.7-beta release on MacOS ARM64 (and confirmed in Lambda ARM64):

date-test.js

const value = {
  date: new Date()
}

console.log(JSON.stringify(value))

Expected output: {"date":"2024-02-20T17:13:17.908Z"}
Received output: {"date":"date":"2024-02-20T17:14:06.578Z"} which is invalid JSON (note the doubling of the "date")

Tested backwards and this appears to work correctly in v0.1.3, and to be broken in subsequent versions

% ./llrt-0.1.3 -v && ./llrt-0.1.3 date-test.js
LLRT (darwin arm64) 0.1.3-beta
{"date":"2024-02-20T17:15:41.779Z"}
% ./llrt-0.1.4 -v && ./llrt-0.1.4 date-test.js
LLRT (darwin arm64) 0.1.4-beta
{"date":"date":"2024-02-20T17:15:51.029Z"}
% ./llrt-0.1.5 -v && ./llrt-0.1.5 date-test.js
LLRT (darwin arm64) 0.1.5-beta
{"date":"date":"2024-02-20T17:15:57.396Z"}
% ./llrt-0.1.6 -v && ./llrt-0.1.6 date-test.js
LLRT (darwin arm64) 0.1.6-beta
{"date":"date":"2024-02-20T17:16:03.466Z"}
% ./llrt-0.1.7 -v && ./llrt-0.1.7 date-test.js
LLRT (darwin arm64) 0.1.7-beta
{"date":"date":"2024-02-20T17:16:08.797Z"}

And just for comparison, how it works in node:

% node -v && node date-test.js
v20.11.0
{"date":"2024-02-20T17:19:23.854Z"}

Hello,

Lambda config:

  Function:
    MemorySize: 256
    Architectures: ["arm64"]
    Runtime: provided.al2
    Layers:
      - !Sub arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:layer:LLRT:1

Deployed with

    Metadata:
      BuildMethod: esbuild
      BuildProperties:
        External:
          - '@aws-sdk/client-eventbridge'
          - '@aws-sdk/client-dynamodb'
          - '@aws-sdk/util-dynamodb'
        Minify: true
        Target: "es2020"
        Sourcemap: false
        EntryPoints: 
          - list.ts

Packages:

  "dependencies": {
    "@aws-sdk/client-dynamodb": "^3.433.0",
    "@aws-sdk/util-dynamodb": "^3.433.0",
    "@aws-sdk/client-eventbridge": "^3.433.0",
    "uuid": "^9.0.1"
  }

Log:

INIT_START Runtime Version: provided:al2.v25 Runtime Version ARN: arn:aws:lambda:eu-central-1::runtime:dce29199fb5887a2c4fceaa2f34d395ba43a74a6895b381cb9383b1c7f3b5875
Binary launched
Decompressing using 2 threads
Extraction time: 13.7280 ms
Extraction + write time: 18.8690 ms
Starting app
ReferenceError: Error resolving module '/var/task/@aws-sdk/client-eventbridge' from '' at <anonymous> (/var/task/insertToSync.js:1:614)
START RequestId: 234d277d-adc9-58b0-a831-7acab3e3ad38 Version: $LATEST
Unknown application error occurred Runtime.Unknown
END RequestId: 234d277d-adc9-58b0-a831-7acab3e3ad38
REPORT RequestId: 234d277d-adc9-58b0-a831-7acab3e3ad38 Duration: 362.75 ms Billed Duration: 363 ms Memory Size: 128 MB Max Memory Used: 12 MB

there currently seems to be no way to do AES en/decryption, which is essential for many applications

require('crypto') doesn't include createCipheriv/createDecipheriv:

and SubtleCrypto doesn't seem to be implemented either

Hello,

as suspected, TLS is the one that blocks the first usage of this LLRT

Lambda config:

  Function:
    MemorySize: 256
    Architectures: ["arm64"]
    Runtime: provided.al2
    Layers:
      - !Sub arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:layer:LLRT:1

Deployed with

    Metadata:
      BuildMethod: esbuild
      BuildProperties:
        External:
          - '@aws-sdk/client-dynamodb'
          - '@aws-sdk/util-dynamodb'
          - '@aws-sdk/client-sqs'
          - '@aws-sdk/node-http-handler'
          - '@aws-sdk/client-sqs'
        Minify: true
        Target: "es2020"
        Sourcemap: false
        EntryPoints: 
          - list.ts

Packages:

  "dependencies": {
    "@aws-sdk/client-dynamodb": "^3.433.0",
    "@aws-sdk/util-dynamodb": "^3.433.0",
    "@aws-sdk/client-sqs": "^3.433.0",
    "@gomomento/sdk": "^1.45.0",
    "uuid": "^9.0.1"
  },

Log:

INIT_START Runtime Version: provided:al2.v25 Runtime Version ARN: arn:aws:lambda:eu-central-1::runtime:dce29199fb5887a2c4fceaa2f34d395ba43a74a6895b381cb9383b1c7f3b5875
Binary launched
Decompressing using 2 threads
Extraction time: 13.0210 ms
Extraction + write time: 17.8990 ms
Starting app
Error resolving module '/var/task/tls' from '/var/task/list.js'
START RequestId: d8cd0ae3-357a-4cbf-83c1-6351390603e8 Version: $LATEST
Unknown application error occurred Runtime.Unknown
END RequestId: d8cd0ae3-357a-4cbf-83c1-6351390603e8
REPORT RequestId: d8cd0ae3-357a-4cbf-83c1-6351390603e8 Duration: 1063.00 ms Billed Duration: 1063 ms Memory Size: 256 MB Max Memory Used: 28 MB

Forgive me as I was unsure if Request was covered by fetch in the compatibility matrix or not, but I noticed when creating a new Request object with an AbortSignal that the same AbortSignal is not then accessible from the signal property of the newly-created object

// index.js
const controller = new AbortController();
const req = new Request('http://localhost/', { signal: controller.signal });

console.log(req.signal);

node index.js
# AbortSignal { aborted: false }

./llrt index.js
# undefined

Description

Add support for
Buffer.concat

Buffer.byteLength

Size

S

I wanted to try out LLRT, but I failed to get base64 decoding to work.

Buffer.from(str, 'base64');

Hello,

Is it possible to bundle the AWS SDK packages into a Lambda layer and connect it to the Lambda, instead of bundling the node_modules into the Lambda itself?

There appears to be an issue parsing static properties on a Class.

Error:

{
  "errorType": "SyntaxError",
  "errorMessage": "invalid property name",
  "stackTrace": [
    "    at /var/task/dist/server/entry.mjs:1878:13",
    ""
  ]
}

Entry File (entry.mjs)

1868: var init_astro_msqbqiov = __esm({
1869:   "dist/server/chunks/astro_msqbqiov.mjs"() {
1870:     "use strict";
1871:     init_colors();
1872:     init_clsx();
1873:     import_cssesc = __toESM(require_cssesc(), 1);
1874:     init_esm();
1875:     __name(normalizeLF, "normalizeLF");
1876:     __name(codeFrame, "codeFrame");
1877:     AstroError = class extends Error {
1878:       static {
1879:         __name(this, "AstroError");
1880:       }
1881:       loc;
1882:       title;
1883:       hint;
1884:       frame;
1885:       type = "AstroError";
1886:       constructor(props, options) {
1887:         const { name, title, message, stack, location, hint, frame: frame2 } = props;
1888:         super(message, options);
1889:         this.title = title;
1890:         this.name = name;
1891:         if (message)
1892:           this.message = message;
1893:         this.stack = stack ? stack : this.stack;
1894:         this.loc = location;
1895:         this.hint = hint;
1896:         this.frame = frame2;
1897:       }

there is the Nodejs built-in process module available to use, and some packages (like mongodb) prefer using it instead of the global module.
The module implementation is pretty simple it re-exports the global module

would it be possible to do the same in llrt?

Hi, how did you create these?

Was it make bench? I can't get that to work on my MBP. https://gist.github.com/kaihendry/02f060a9499582fc0e598eb0eeb31643

My goal was to compare my project without llrt and then incorporate llrt and run the benchmark again. So ideally it's some github action or something.

Hi!

I tried to apply Profile-Guided Optimization (PGO) to optimize llrt performance further (as I already did for many other projects - see all current results here). I performed some basic benchmarks and want to share the results here.

Test environment

• Fedora 39
• Linux kernel 6.7.3
• AMD Ryzen 9 5900x
• 48 Gib RAM
• SSD Samsung 980 Pro 2 Tib
• Compiler - Rustc 1.76
• llrt version: the latest for now from the main branch on commit c040bfd05a2be8d3300e7a1bbfc9405c42a865fa
• Disabled Turbo boost (for more stable results across benchmark runs)

Benchmark

As a benchmark, I use the same command as I found in the Makefile - llrt fixtures/hello.js. The same scenario is used for the PGO training phase. All PGO optimization steps are done with cargo-pgo tool. PGO instrumented version is built with cargo pgo build, PGO optimized version - cargo pgo optimize build. taskset -c 0 is used for reducing CPU scheduling influence on the results.

Results

I got the following results:

hyperfine -u microsecond -N --warmup=2000 --min-runs 10000 "taskset -c 0 ./llrt_optimized ../fixtures/hello.js" "taskset -c 0 ./llrt_release ../fixtures/hello.js"
Benchmark 1: taskset -c 0 ./llrt_optimized ../fixtures/hello.js
  Time (mean ± σ):     2664.8 µs ±  78.8 µs    [User: 590.1 µs, System: 1943.3 µs]
  Range (min … max):   2478.1 µs … 4486.1 µs    10000 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: taskset -c 0 ./llrt_release ../fixtures/hello.js
  Time (mean ± σ):     2796.1 µs ±  63.6 µs    [User: 601.4 µs, System: 2068.9 µs]
  Range (min … max):   2647.5 µs … 4495.0 µs    10000 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  taskset -c 0 ./llrt_optimized ../fixtures/hello.js ran
    1.05 ± 0.04 times faster than taskset -c 0 ./llrt_release ../fixtures/hello.js

, where llrt_release - usual Release version, llrt_optimized - PGO-optimized version.

I ran the benchmark multiple times, with different command orders, etc - in all cases, the PGO-optimized version was faster than the usual release version. However, it would be awesome to perform some more precise benchmarks.

Further steps

I can suggest to do the following things:

• Perform more PGO benchmarks with some more precise performance measurements.
• If PGO is worth it - add a note to the documentation about it and, possibly, make an option in the build scripts to optimize llrt easier with the existing build infrastructure.
• Try to play with Post-Link Optimization (PLO) with tools like LLVM BOLT.

I hope these benchmark results can be interesting to someone.

Hey!
I tried to run the test with make run but it fails with Error resolving module 'xx/lambda-llrt/index' from '@llrt/runtime'
Tracking down the error, it comes from https://github.com/awslabs/llrt/blob/main/src/js/%40llrt/runtime.ts#L214

I had to manually hardcode the .mjs extension in src/js/@llrt/runtime.ts so the line becomes

const handlerModule = await import(`${taskRoot}/${moduleName}.mjs`);

Does it work on your side without it? Which version of node are you using?

Create an upgrade action via CLI.
llrt upgrade

This could query the Github repo (via the API) and pull down latest release according to the users OS.

Is there a way to save code coverage details when running tests?

Under NodeJS the env var NODE_V8_COVERAGE allows to save the V8 coverage, Bun, and Deno both have a --coverage flag.

Would be great to have this also in LLRT. That said, I don't see any support in QuickJS, and instrumenting code (a-la NYC/Istanbul) can be a bit of a hassle...

Hello,
I encountered an error when trying to use a callback function in AWS Lambda Authorizer.

Here is my implementation.
The authentication process has been excluded.

export const handler = async (event, context, callback) => {

  var authResponse = buildAllowAllPolicy(event, 'foo');
  callback(null, authResponse);
};

function buildAllowAllPolicy (event, principalId) {
  const policy = {
    principalId: principalId,
    policyDocument: {
      Version: '2012-10-17',
      Statement: [
        {
          Action: 'execute-api:Invoke',
          Effect: 'Allow',
          Resource: event.methodArn
        }
      ]
    }
  };
  return policy;
}

START RequestId: e50ca89a-72c6-436f-9534-9b7d9fe2cf99 Version: $LATEST
2024-02-19T13:34:52.844Z	e50ca89a-72c6-436f-9534-9b7d9fe2cf99	ERROR	    at handler (/var/task/index.mjs:4:3)
at startProcessEvents (@llrt/runtime:5:187)
2024-02-19T13:34:52.844Z	e50ca89a-72c6-436f-9534-9b7d9fe2cf99	ERROR	{
  errorType: 'TypeError',
  errorMessage: 'not a function',
  stackTrace: [ '    at handler (/var/task/index.mjs:4:3)', '    at startProcessEvents (@llrt/runtime:5:187)', '' ],
  requestId: 'e50ca89a-72c6-436f-9534-9b7d9fe2cf99'
}
END RequestId: e50ca89a-72c6-436f-9534-9b7d9fe2cf99
REPORT RequestId: e50ca89a-72c6-436f-9534-9b7d9fe2cf99	Duration: 1.71 ms	Billed Duration: 35 ms	Memory Size: 128 MB	Max Memory Used: 21 MB	Init Duration: 32.70 ms	

Do you know what could be the cause?

Description

When you try to download an object from S3, the S3Client throws an exception instead :

2024-02-13T02:05:55.689Z	fc15815e-245d-4d51-8633-24deabb3699e	ERROR	    at Fr (llrt-chunk-sdk-GKKMFRJI.js:6:131)
--
at _g (@aws-sdk/client-s3:1:55290)
at <anonymous> (llrt-chunk-sdk-SXB3ZJRL.js:1:14739)
2024-02-13T02:05:55.689Z	fc15815e-245d-4d51-8633-24deabb3699e	ERROR	{  errorType: 'Error',  errorMessage: 'Unexpected stream implementation, expect Blob or ReadableStream, got Uint8Array
Deserialization error: to see the raw response, inspect the hidden field {error}.$response on this object.',  stackTrace: [ '    at Fr (llrt-chunk-sdk-GKKMFRJI.js:6:131)', '    at _g (@aws-sdk/client-s3:1:55290)', '    at <anonymous> (llrt-chunk-sdk-SXB3ZJRL.js:1:14739)', '' ],  requestId: 'fc15815e-245d-4d51-8633-24deabb3699e'}

To reproduce

1. Deploy the stack in llrt/example/infrastructure using CDK
2. Access the URL : https://API_GW/llrt-s3
3. Replace the PutObjectCommand in : llrt/example/functions/src/v3-s3.mjs with a GetObjectCommand like below

    s3Client.send(
      new GetObjectCommand({
        Bucket: process.env.BUCKET_NAME,
        Key: "<KEY_OF_FILE_UPLOADED_AT_STEP_2>",
      })
    ),

4. Bug you will see the exception above.