Skip to content

4.0.1 Does Not Resolve Modules Relative to Working Directory #184

@ptefft-bizequity

Description

@ptefft-bizequity

Dockerfile

I have a Dockerfile that has previously worked with RIC 3.3.0, following the conventions described in the README for the 22.x branch. It does not work on 4.0.1 I think because 4.0.1 fundamentally doesn't care about the current working directory anymore in favor of the LAMBDA_TASK_ROOT environment variable.

3.3.0 Behavior

In 3.3.0, (nodejs22.x branch), bin/index.mjs pulls the current working directory and uses that as the app root.

const appRoot = process.cwd();
const handler = process.argv[2];
  
console.log(`Executing '${handler}' in function directory '${appRoot}'`);
await run(appRoot, handler);

This works with the conventions on the 22.x README, which encourage me to put the handler at a relatively arbitrary FUNCTION_DIR that we also set as the working directory.

I wasn't able to find LAMBDA_TASK_ROOT in the source code on this branch.

4.0.1 Behavior

When moving to 4.0.1 (nodejs24.x branch), we get this error on AWS Lambda:

2026-01-27T19:25:52.402Z	-	ERROR	Init Error 	
{
    "errorType": "Runtime.ImportModuleError",
    "errorMessage": "Error: Cannot find module 'lambda'\nRequire stack:\n- /function/node_modules/aws-lambda-ric/index.mjs",
    "name": "Runtime.ImportModuleError",
    "stack": [
        "Runtime.ImportModuleError: Error: Cannot find module 'lambda'",
        "Require stack:",
        "- /function/node_modules/aws-lambda-ric/index.mjs",
        "    at loadModule (file:///function/node_modules/aws-lambda-ric/index.mjs:575:13)",
        "    at async UserFunctionLoader.load (file:///function/node_modules/aws-lambda-ric/index.mjs:506:20)",
        "    at async createRuntime (file:///function/node_modules/aws-lambda-ric/index.mjs:1219:52)",
        "    at async ignition (file:///function/node_modules/aws-lambda-ric/index.mjs:1635:21)"
    ]
}

I don't see anything that tries to resolve the module against the working directory. It seems to rely only on the LAMBDA_TASK_ROOT environment variable.

24.x Docs

The README for the 24.x branch covers building a Lambda image using an arbitrary-ish base Docker image here.

These docs continue to use an arbitrary FUNCTION_DIR and don't seem to include any steps for copying handler code into the image, which leaves me with some questions.

Questions

Is this behavior change expected/intentional?

If it is, I have the following questions as someone building an image from scratch, and we may want to clarify the README:

  • As someone building an image, should I set a LAMBDA_TASK_ROOT variable pointing to where I put the handler module as the official images do (e.g. public.ecr.aws/lambda/nodejs:22)?
  • Is it important or helpful for me to use /var/task as LAMBDA_TASK_ROOT or is it arbitrary?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions