Upgrading to 4.0.0 appears to break lambdas using docker

[fabiancook]

I had been using

RUN npm install -g aws-lambda-ric

Which is on me for not pinning it to a specific version, but with this after the 4.0.0 release on a new build of an image the lambda will no longer start.

2025-12-06T02:12:47.652Z | npm error could not determine executable to run
-- | --
  | 2025-12-06T02:12:47.653Z | npm error A complete log of this run can be found in: /tmp/.npm/_logs/2025-12-06T02_12_46_306Z-debug-0.log
  | 2025-12-06T02:12:47.664Z | INIT_REPORT Init Duration: 1421.03 ms Phase: init Status: error Error Type: Runtime.ExitError

Pinning to 3.3.0 allows our service to run.

RUN npm install -g aws-lambda-ric@3.3.0

This is across multiple projects for separate company stacks I am seeing this. I've pinned to 3.3.0 across the board.

This is running with node:24 as a base image, and had experienced with a node:23 deployment.

Here is an example of what is being used for the entrypoint with aws-lambda-ric:

ENTRYPOINT ["/usr/local/bin/npx", "aws-lambda-ric"]
CMD ["lib/serverless/lambda/lambda.handler"]

Noting again that after pinning the lambdas work as expected.

This is too similar to the pattern shown here, where the version is unpinned:

aws-lambda-nodejs-runtime-interface-client/README.md

Line 102 in a4560c8

RUN npm install aws-lambda-ric

[MK99Patel]

I am experiencing the same issue. Until two days ago, our Lambda functions were running without any problems using aws-lambda-ric@3.3.0 on a node:22-alpine base image. However, builds are now completely breaking, even when explicitly installing version 3.3.0 for backward compatibility.

Below is the Dockerfile example:

`FROM node:22-alpine

ARG FUNCTION_DIR="/microservice"

RUN apk add --no-cache bash curl cmake autoconf automake gcc gcc-c++ g++ xz make libtool build-base python3 python3-dev py3-pip
RUN apk add --no-cache --update --repository=https://dl-cdn.alpinelinux.org/alpine/v3.16/main/
libexecinfo
libexecinfo-dev

RUN mkdir -p ${FUNCTION_DIR}
WORKDIR ${FUNCTION_DIR}
ADD . ${FUNCTION_DIR}

RUN npm install

RUN npm install aws-lambda-ric

RUN cp .env.example .env &&
npm run build

ENTRYPOINT ["npx", "aws-lambda-ric"]

CMD ["dist/app/index.handler"]
`

Even when pinning to the previous working version (npm install aws-lambda-ric@3.3.0), the Lambda no longer starts as expected. This suggests that something may have changed externally that is impacting both the latest release and older versions.

Has anything changed recently that could affect Alpine-based Node runtimes or the runtime interface client behavior? Any guidance would be greatly appreciated.

[fabiancook]

@MK99Patel how are you pinning it?

I had a thought too when not installed globally you may need to check in your package that it isn't given a range there already too.

I could definitely toggle the issue off by using

RUN npm install -g aws-lambda-ric@3.3.0

[NithinBiliya]

+1

[HenrikFricke]

+1

[godcrampy]

Thanks for bringing this up, investigating on priority. The old RIC which can be installed by running: npm install -g aws-lambda-ric@3.3.0 is still stable. v4.0.0 is introduced for Node.js 24 workloads although v3.x.x can still run on all supported Node.js versions as a workaround.

[godcrampy]

In the meantime, I've marked 4.0.0 as preview and 3.3.0 as latest on npm to prevent surprises.

[MK99Patel]

@godcrampy
I am not sure it's only me or not but running docker with aws-lambda-ric@3.3.0 version is also not working from Friday onwards.

Error: Error relocating /microservice/node_modules/aws-lambda-ric/dist/rapid-client.node: backtrace_symbols: symbol not found
at Object..node (node:internal/modules/cjs/loader:1865:18)
at Module.load (node:internal/modules/cjs/loader:1441:32)
at Function._load (node:internal/modules/cjs/loader:1263:12)
at TracingChannel.traceSync (node:diagnostics_channel:328:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:237:24)
at Module.require (node:internal/modules/cjs/loader:1463:12)
at require (node:internal/modules/helpers:147:16)

`
FROM node:22-alpine

RUN apk add --no-cache bash curl cmake autoconf automake libtool build-base python3 python3-dev py3-pip
RUN apk add --no-cache --update --repository=https://dl-cdn.alpinelinux.org/alpine/v3.16/main/ libexecinfo-dev

RUN mkdir -p /microservice
WORKDIR /microservice
ADD . /microservice

RUN ls -la /microservice

RUN npm install

RUN npm i aws-lambda-ric@3.3.0

CMD ["node_modules/.bin/aws-lambda-ric", "dist/app/index.handler"]
`

Above is the Dockerfile that we tend to be running since long time and it suddenly broke from Friday onwards.

[MK99Patel]

@godcrampy

I am not defining aws-lambda-ric at package.json. It only defined at Docker level only.

Tried both way with/without using "-g" but still same issue.

This is what version installed:
RUN npm list aws-lambda-ric --depth=0

output:
`-- aws-lambda-ric@3.3.0

[jkburges]

I am not sure it's only me or not but running docker with aws-lambda-ric@3.3.0 version is also not working from Friday onwards.

FWIW, pinning is not solving the issue for me, either. So you are not alone @MK99Patel.

Update: pinning to v3.3.0 does fix the issue for me. I had a misconfiguration in my dev setup (missing env var) in the Datadog wrapper we use; solving that and things now work on 3.3.0 for me, just in case that helps.

[hjbrock]

+1. Backing up to 3.3.0 keeps us running, but we need to upgrade to 4.0.0 for node 24 support, so this is blocking. On inspection, it does look like there's no binary post-install for 4.0.0. Or, at least, not in the expected location. Which explains npm error could not determine executable to run.

[godcrampy]

Hey folks, I've published v4.0.1 (as a preview) which includes a fix for this issue. I was able to reproduce and verify the fix on my end. Could you please validate by installing the updated package?

npm install aws-lambda-ric@4.0.1

Let me know if this resolves the issue for you.

[hjbrock]

@godcrampy thanks! I can get the runtime started now. I've made no other changes to our Dockerfile other than updating the node version to 24 and aws-lambda-ric version to 4.0.1. We now have two separate issues:

1. When running with the runtime emulator, LAMBDA_TASK_ROOT isn't set, and the ric throws an error about the missing task root var. We can just set this manually and get around it, but thought you'd like to know since it's different behavior than 3.3.0.
2. When running in AWS, I get this:

at async ignition (file:///usr/lib/node_modules/aws-lambda-ric/index.mjs:1635:21)
at createRuntime (file:///usr/lib/node_modules/aws-lambda-ric/index.mjs:1212:11)
PlatformError [Runtime.PlatformError]: _HANDLER environment variable is not set
^
throw new PlatformError("_HANDLER environment variable is not set");
file:///usr/lib/node_modules/aws-lambda-ric/index.mjs:1212

We don't see this with 3.3.0, either, with the same Dockerfile. Setting _HANDLER ourselves is clearly a no-go as it's intended to be reserved and gets overwritten as empty anyway if set in the image (I did test this just to be sure). We can set it in an entrypoint script and override it with the right value at runtime, but the documented way of using a custom base image does not work with 4.0.1 currently.