Introduction

When one Node.js Lambda tries to call another and nothing seems to happen, the problem is usually configuration rather than code shape. The common causes are missing lambda:InvokeFunction permission, a wrong function name or alias, a region mismatch, or confusion about what the Invoke response actually guarantees.

The fix is to reduce the call path to a minimal example and then verify each assumption one by one. Once you can see the raw response and the target logs, Lambda-to-Lambda invocation becomes much easier to reason about.

Start With a Minimal Invoke Call

Use the AWS SDK for JavaScript v3 and keep the first test explicit. That gives you a clean baseline before any framework wrappers or shared helpers get involved.

1import { LambdaClient, InvokeCommand } from "@aws-sdk/client-lambda";
2
3const client = new LambdaClient({ region: process.env.AWS_REGION });
4
5export const handler = async () => {
6  const command = new InvokeCommand({
7    FunctionName: process.env.TARGET_FUNCTION_NAME,
8    InvocationType: "RequestResponse",
9    Payload: Buffer.from(JSON.stringify({ jobId: "123" })),
10  });
11
12  const response = await client.send(command);
13  const payloadText = response.Payload
14    ? Buffer.from(response.Payload).toString("utf8")
15    : "";
16
17  console.log("StatusCode:", response.StatusCode);
18  console.log("FunctionError:", response.FunctionError);
19  console.log("Payload:", payloadText);
20
21  return { ok: true };
22};

For RequestResponse, Lambda returns metadata plus the target function payload. If the target handler threw, FunctionError is the first field to inspect. A StatusCode of 200 means the invocation request was accepted and executed synchronously. It does not mean your business logic succeeded.

Check IAM and the Target Identifier

The caller Lambda runs under an execution role, and that role must be allowed to invoke the target function.

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Action": "lambda:InvokeFunction",
7      "Resource": "arn:aws:lambda:us-east-1:123456789012:function:target-fn"
8    }
9  ]
10}

That permission must line up with what you actually call. If your code invokes target-fn:prod but your policy or environment variable points somewhere else, the symptom looks like a broken call even though the SDK usage is fine.

The function identifier can be a simple name, a name with alias, or a full ARN:

1const command = new InvokeCommand({
2  FunctionName: "target-fn:prod",
3  InvocationType: "RequestResponse",
4  Payload: Buffer.from(JSON.stringify({ source: "caller" })),
5});

Be precise about the alias and region. Many debugging sessions boil down to discovering that the caller is configured for one region while the target function exists in another.

Understand RequestResponse Versus Event

Invocation mode changes the meaning of success.

1const command = new InvokeCommand({
2  FunctionName: process.env.TARGET_FUNCTION_NAME,
3  InvocationType: "Event",
4  Payload: Buffer.from(JSON.stringify({ reportId: "r-42" })),
5});

With RequestResponse, the caller waits and can inspect the target result immediately. With Event, the caller only learns that Lambda accepted the event for asynchronous processing. If the downstream function later fails, that failure will not come back in the caller's payload. You need CloudWatch logs, destinations, or dead-letter handling to see it.

That distinction matters because many "not calling another Lambda" reports are actually asynchronous failures in the target function after the caller already returned successfully.

Make the Target Function Easy to Inspect

A small amount of logging in the target function saves a lot of guesswork.

1export const handler = async (event) => {
2  console.log("target received:", JSON.stringify(event));
3
4  if (!event.jobId) {
5    throw new Error("jobId is required");
6  }
7
8  return {
9    processed: true,
10    jobId: event.jobId,
11  };
12};

If a manual test from the AWS console or CLI reaches this function, but the caller Lambda does not, focus on the caller's IAM policy and region settings. If even the manual test fails, fix the target function first before debugging the chain.

Common Pitfalls

The most common mistake is treating a successful response status as proof that the target logic completed correctly. For synchronous calls, always inspect FunctionError and decode the payload. Another frequent mistake is using InvocationType: "Event" but expecting an immediate return value from the target handler.

The next cluster of issues is configuration drift: wrong alias, wrong ARN, wrong region, or an execution role that does not have permission to invoke the target. It is also easy to forget timeouts. If the caller waits synchronously for a slow target and its own timeout is too short, the whole pattern becomes unreliable.

Summary

• Use a minimal InvokeCommand call and log the raw response fields.
• Check FunctionError and the returned payload for synchronous invocations.
• Verify the caller role has lambda:InvokeFunction on the target function or alias.
• Confirm the function name, alias, ARN, and region all match the real deployment.
• Remember that InvocationType: "Event" is asynchronous and does not return the target result.