'ILambdaContext.InvokedFunctionArn' always returning 'null'

[julealgon]

Description

I've created a new lambda function and I wanted to get the ARN for the function to pass along into my code for further processing. However, ILambdaContext.InvokedFunctionArn is always returning null, both when testing locally, as well as when calling the function in the real environment.

The documentation for the property does not state it can ever be null:

The ARN used to invoke this function. It can be function ARN or alias ARN. An
unqualified ARN executes the $LATEST version and aliases execute the function
version they are pointing to.

Reproduction Steps

1. Create empty lambda
2. Access the InvokedFunctionArn property in the ILambdaContext passed into the function
3. Check that the value is always null

Environment

• Package Version: Amazon.Lambda.Core v1.2.0
• OS Info: Windows 10
• Build Environment Visual Studio 2019
• Targeted .NET Platform: NetCore 3.1

Resolution

• 👋 I can/would-like-to implement a fix for this problem myself

---

This is a 🐛 bug-report

[ashishdhingra]

Hi @julealgon,

Thanks for reporting the issue.

Unfortunately, using the latest Amazon Lambda Tools for .NET Core applications (5.0.1), I'm unable to reproduce the issue. Here are the steps:

• Used reference at (https://docs.aws.amazon.com/lambda/latest/dg/csharp-package-cli.html) to generate .NET project for empty lambda function. Below are the generated files:
  .csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <GenerateRuntimeConfigurationFiles>true</GenerateRuntimeConfigurationFiles>
    <AWSProjectType>Lambda</AWSProjectType>

    <!-- This property makes the build directory similar to a publish directory and helps the AWS .NET Lambda Mock Test Tool find project dependencies. -->
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Amazon.Lambda.Core" Version="1.2.0" />
    <PackageReference Include="Amazon.Lambda.Serialization.SystemTextJson" Version="2.1.0" />
  </ItemGroup>
</Project>

Function.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;

using Amazon.Lambda.Core;

// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]

namespace MyFunction
{
    public class Function
    {
        
        /// <summary>
        /// A simple function that takes a string and does a ToUpper
        /// </summary>
        /// <param name="input"></param>
        /// <param name="context"></param>
        /// <returns></returns>
        public string FunctionHandler(string input, ILambdaContext context)
        {
            Console.WriteLine($"ILambdaContext.InvokedFunctionArn: {context.InvokedFunctionArn}");
            return input?.ToUpper();
        }
    }
}

Take note that I'm logging the value of ILambdaContext.InvokedFunctionArn to output which would log in CloudWatch Logs.

aws-lambda-tools-defaults.json

{
  "Information": [
    "This file provides default values for the deployment wizard inside Visual Studio and the AWS Lambda commands added to the .NET Core CLI.",
    "To learn more about the Lambda commands with the .NET Core CLI execute the following command at the command line in the project root directory.",
    "dotnet lambda help",
    "All the command line options for the Lambda command can be specified in this file."
  ],
  "profile": "",
  "region": "us-east-2",
  "configuration": "Release",
  "framework": "netcoreapp3.1",
  "function-runtime": "dotnetcore3.1",
  "function-memory-size": 256,
  "function-timeout": 30,
  "function-handler": "MyFunction::MyFunction.Function::FunctionHandler"
}

• Executed .NET CLI command dotnet lambda deploy-function MyFunction --function-role myfunction-role to deploy Lambda function (where I have created role named myfunction-role with AWSLambdaBasicExecutionRole policy in AWS IAM Console)

• Executed .NET CLI command dotnet lambda invoke-function MyFunction --payload "Just Checking If Everything is OK" to invoke Lambda function. Here's the output:

Amazon Lambda Tools for .NET Core applications (5.0.1)
Project Home: https://github.com/aws/aws-extensions-for-dotnet-cli, https://github.com/aws/aws-lambda-dotnet
	
Payload:
"JUST CHECKING IF EVERYTHING IS OK"

Log Tail:
START RequestId: 4e7edb54-1989-426b-aa7c-554a4fc30ab0 Version: $LATEST
ILambdaContext.InvokedFunctionArn: arn:aws:lambda:us-east-2:139480602983:function:MyFunction
END RequestId: 4e7edb54-1989-426b-aa7c-554a4fc30ab0
REPORT RequestId: 4e7edb54-1989-426b-aa7c-554a4fc30ab0	Duration: 469.06 ms	Billed Duration: 470 ms	Memory Size: 256 MB	Max Memory Used: 66 MB	Init Duration: 160.42 ms	

Screenshot from CloudWatch

As you could see from the above screenshot and command execution output, the ILambdaContext.InvokedFunctionArn value is properly logged.

Are you trying to execute the function using the Mock Lambda Test tool? In that case the value could be null since the function is not executing inside the AWS environment and there is no concept of ARN when running under Mock Lambda Test tool.

Thanks,
Ashish

[julealgon]

Hey @ashishdhingra . Sorry for making you go through these repros as it was a silly mistake on my end this time.

I initially tested with the MockLambdaTool and figured it would not populate the field there. Then I proceeded to test in the actual environment but still got the same error in my application. Turns out however that the error was caused by something else, and I can see the ARN being returned in the real environment indeed.

However, I'd like to still propose something for consideration here. The fact that the values in MockLambdaTool are all null is less than ideal. As you are aware, it is usually a bad idea to code something in the application that covers behavior that only happens during testing: the application code should not need to know whether it is running in a test or not. Due to the fact that the ARN is null during testing, we'd need to add extra checks in code to avoid using that null value, even though the value is always supposed to exist in the "production" version.

Do you think it would be possible to ask the team to actually populate a dummy ARN in the InvokedFunctionArn field during testing, so that the mocked ILambdaContext actually reflects a more realistic scenario in terms of interface contracts? Perhaps just by omiting the "account" and "region" components of the ARN it would already be enough, so in your example:

• arn:aws:lambda:::function:MyFunction

See, nullability of fields is something that is part of the contract of the interface, and all implementations should follow that same contract. By having the test implementation return null, you are basically violating Liskov Substitution and forcing the consuming code to adapt to both contracts.

Hope that makes sense, and apologies again for misleading you.

[ashishdhingra]

Hi @julealgon,

Good morning.

While I agree it is a pain point for having to handle a null condition which only exists during testing locally, setting dummy value for ILambdaContext.InvokedFunctionArn would not be correct since it would not point to valid ARN and could result to logical/consistency issues if ARN is used further down in the business logic (as you are tying to use it in EventBridge API). Kindly note that there is no mocking of EventBridge API and for invalid ARNs it may return a different type of error.

I will discuss this with development team and get their inputs.

Thanks,
Ashish

[julealgon]

@ashishdhingra

would not be correct since it would not point to valid ARN

But that's the point. Isn't this a valid ARN for a lambda?

• arn:aws:lambda:::function:MyFunction

There is nothing there that the test environment couldn't generate on the fly. It's not that it would be lying as well, the information that is there is correct.

[ashishdhingra]

@ashishdhingra

would not be correct since it would not point to valid ARN

But that's the point. Isn't this a valid ARN for a lambda?

• arn:aws:lambda:::function:MyFunction

There is nothing there that the test environment couldn't generate on the fly. It's not that it would be lying as well, the information that is there is correct.

@julealgon There is a valid ARN for Lambda in the production environment, but not in a Mock environment. If you refer the ARN arn:aws:lambda:us-east-2:139480602983:function:MyFunction reported in the log, it is a combination of region, account ID and function name. Mock Lambda Test tool cannot assume valid values for these parameters; if it does, it would not be valid ARN for logical purposes. I will discuss this with development team and share their inputs accordingly.

[julealgon]

Mock Lambda Test tool cannot assume valid values for these parameters; if it does, it would not be valid ARN for logical purposes.

The point I'm trying to make is that an ARN that does not have a "region" and "account" is still a valid ARN. I'm using stepfunctions quite heavily lately and most ARNs used there are like this: they are simpler versions of the full ARNs since the environment can tell the attributes when executing.

This is why it seems to me that a lambda ARN without region and account would still be a valid ARN and could be used by the test tools.