Exit 254 lambda error with no extra explanations

In case it helps someone else looking at this... I had an identical issue pop up last week using a node:16 image, which had recently been updated to node:16.15.1. I rolled back to node:16.14.2 to get it working again.

For me it happened when the playwright container was updated to 1.23.X, which uses node 16.16.X. Tried to downgrade the Node in the dockerfile after fetching the playwright container, but it didn't help. Since I couldn't identify what breaking change may have caused it, so as temporary solution I pinned the version of playwright docker image my code uses to v1.22.2, and my lambda is working again.

Your Docker image must be built on the same CPU architecture as the architecture you configure for your Lambda function. Building a Docker image on a Mac with an M1 CPU usually produces an image for the Linux/arm64 architecture, so your Lambda function must be configured for the arm64 architecture as well.

If you're using Docker Desktop on an M1 Mac, you can also produce x86 images using docker buildx build that can be deployed onto Lambda using the x86 architecture. You'll want to pass the --platform=linux/amd64 argument to this command.

By the way, we have successfully tested running Chromium on Lambda on Graviton. If you start with the fedora:36 or fedora:35 base images, you can install prebuilt Chromium RPMs from the Fedora package repository. See, e.g., https://fedora.pkgs.org/36/fedora-aarch64/chromium-99.0.4844.51-1.fc36.aarch64.rpm.html

Yes you could append the host platform on it. But the issue is a difference between where you build the image and the Architecture setting on the lambda.

Example: if you build the image on an m1 mac push to ECR and set the Architecture setting to x86_64 then you will get this error.

You can either change the setting in lambda or if you are working with multiple people on different systems Id suggest using CodePipeline with a CodeBuild step and you can define the system the pipeline builds on so every-time the build is consistent with a buildspec.yaml like this.

version: 0.2 
 
phases: 
  install: 
    runtime-versions: 
      docker: 18 
  pre_build: 
    commands: 
      - echo Logging in to Amazon ECR... 
      - aws --version 
      - $(aws ecr get-login --region $AWS_DEFAULT_REGION --no-include-email) 
      - REPOSITORY_URI=$EcrRepo
      - COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
      - IMAGE_TAG=${COMMIT_HASH:=latest}
  build: 
    commands: 
      - echo Build started on `date` 
      - echo Building the Docker image... 
      - docker build -t $REPOSITORY_URI:latest .
      - docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
  post_build:
    commands:
      - echo Build completed on `date`
      - echo Pushing the Docker images...
      - docker push $REPOSITORY_URI:latest
      - docker push $REPOSITORY_URI:$IMAGE_TAG
      - aws lambda update-function-code --function-name [YOUR_FUNCTION_NAME] --image-uri $REPOSITORY_URI:$IMAGE_TAG

Is there any news regarding this? We still have this problem in October. We could not figure out what was going on as there is no log other than error 254. Tried Playwright version 1.27.1 and different docker images, all ubuntu 20.4 and node 16.17.1. Locally they work without issues. We tried putting the container in a k8s pod and it works as well.. It appears there is some sort of problem on the lambda container side, but who knows other than "error 254". We also tried going gradually backwards with playwright version by version, and the only one working is the 1.22.2 as other pointed out

Thanks everyone for all the help - I ran into this issue yesterday. Building the image on my linux machine instead of my m1 macbook pro and then downgrading to the playwright v1.22.2 image both got me past this error. Now, on to fix the next errors!