.net 6 runtime vs .net 3.1 runtime thread handling

[mleziva]

When upgrading a .netcoreapp3.1 to .net6 on lambda, I noticed that lambda now handles the requests in a different thread than the function initialization. Using the test below, I can see that the .net3.1 runtime executes the function constructor and the functionHandler on the same thread and the async value is maintained. Executing the same test on .net6 we can see that the constructor is called on a different thread than the functionHandler and the async value is not retained.

Here is the sample code:

using Amazon.Lambda.Core;
using System;
using System.Threading;

// 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 AwsLambdaNetCore3
{
    public class Function
    {
        private readonly AsyncLocal<int> AsyncTestValue =
                new AsyncLocal<int>();
        public Function()
        {
            AsyncTestValue.Value = 1;
            Console.WriteLine($"Constructor Thread ID: {Environment.CurrentManagedThreadId}");
            Console.WriteLine($"AsyncTestValue: {AsyncTestValue.Value}");
        }
        /// <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($"AsyncTestValue: {AsyncTestValue.Value}");
            Console.WriteLine($"Handler Thread ID: {Environment.CurrentManagedThreadId}");
            return input.ToUpper();
        }
    }
}

Output on .net3.1 runtime:

Constructor Thread ID: 1
AsyncTestValue: 1
START RequestId: 2d474e6a-4b92-4367-880f-0b4dcc6de307 Version: $LATEST
AsyncTestValue: 1
Handler Thread ID: 1
END RequestId: 2d474e6a-4b92-4367-880f-0b4dcc6de307
REPORT RequestId: 2d474e6a-4b92-4367-880f-0b4dcc6de307	Duration: 214.69 ms	Billed Duration: 215 ms	Memory Size: 256 MB	Max Memory Used: 53 MB	Init Duration: 192.49 ms	

output on .net6 runtime:

2023-02-01T16:28:40.663Z		info	Constructor Thread ID: 1
2023-02-01T16:28:40.673Z		info	AsyncTestValue: 1
START RequestId: 31674168-3648-4191-8bc3-e240d24e328d Version: $LATEST
2023-02-01T16:28:40.946Z	31674168-3648-4191-8bc3-e240d24e328d	info	AsyncTestValue: 0
2023-02-01T16:28:40.946Z	31674168-3648-4191-8bc3-e240d24e328d	info	Handler Thread ID: 7
END RequestId: 31674168-3648-4191-8bc3-e240d24e328d
REPORT RequestId: 31674168-3648-4191-8bc3-e240d24e328d	Duration: 379.80 ms	Billed Duration: 380 ms	Memory Size: 256 MB	Max Memory Used: 62 MB	Init Duration: 201.28 ms	

Does anyone know the reason for this change and if it was documented anywhere? I don't see it in the blog post which has upgrade steps: https://aws.amazon.com/blogs/compute/introducing-the-net-6-runtime-for-aws-lambda/

[normj]

For .NET 6 we switched to our open source version of the Lambda runtime client written in C# from the previous internal Lambda runtime client which was written largely in C. We called this out in the mentioned blog post of the switch knowing there would some subtle changes in behavior like this. The fact that 3.1 called the constructor on the same thread as the function handler was never an intentional design goal. Sorry if this change in behavior is causing you issues.

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.