ILambdaLogger.LogLine(...) behaviour changed between .Net 5 and .Net 6

Description

In .Net 5, ILambdaLogger.LogLine(“hello world”) would be logged to CloudWatch Logs exactly as

hello world

After changing my Lambda project’s TargetFramework from net5.0 to net6.0, the same call to ILambdaLogger.LogLine is logged to CloudWatch Logs as “{timestamp}\t{requestId}\t{level}\t{message}”

2021-11-14T21:32:01.022Z	8247f3ba-2335-4b12-bf19-e379605ba146	info	hello world

In my real Lambda project, my message is a json string which I subsequently deserialise. With the new behaviour in .Net 6, the message is no longer valid json because of the extra tab-delimited fields in each message.

Reproduction Steps

In a custom runtime Lambda, set the function handler to this

public static DateTime FunctionHandler(ILambdaContext context)
{
    context.Logger.LogLine("hello world");
    return DateTime.UtcNow;
}

Deploy this Lambda using TargetFramework net5.0 then invoke the function and check the CloudWatch Logs output. The log event’s message will be “hello world”. Deploy the Lambda again using TargetFramework net6.0 then invoke the function again and check the CloudWatch Logs output again. The log event’s message will have tab-delimited fields followed by “hello world”.

Environment

• Build Version: Amazon.Lambda.Core 2.1.0
• OS Info: AmazonLinux2
• Build Environment: docker
• Targeted .NET Platform: net5.0 and net6.0

Resolution

I would like the .Net 6 behaviour to return to the previous .Net 5 behaviour where the log event’s message is exactly as I passed to ILambdaLogger.LogLine(…)

This is a 🐛 bug-report

[martincostello]

Just found this issue. Not urgent, but would it be possible to have this exposed programmatically?

We have an internal framework which builds on top of this library we use in a number of different Lambda solutions, where this library is referenced transitively. We also use JSON-formatted logging.

To apply this fix, as well as updating our framework library, this also needs us to apply the environment variable in each lambda project. It would be easier to roll out the fix centrally if our base library could just set the level to Unformatted itself.

[normj]

The change was done on purpose because getting request id in the logging statement like other Lambda runtimes was a highly requested feature. I understand your use case of wanting to pass in a JSON string to logline. If we had an environment variable that allowed you to opt in the old behavior would that work for you?