JSON log format pairs ILogger message template placeholders with state values by position, garbling ASP.NET Core hosting logs

[madmox]

Describe the bug

When a function uses LoggingConfig.LogFormat: JSON and bridges Microsoft.Extensions.Logging.ILogger to the Lambda logging API via Amazon.Lambda.Logging.AspNetCore, structured log events can come out with their JSON properties holding the wrong values (each property shifted to a neighboring placeholder's value).

Root cause, as far as I can tell, is a combination of two behaviors:

1. LambdaILogger extracts the message template from {OriginalFormat} and collects the state values in state enumeration order (LambdaILogger.cs).
2. JsonLogMessageFormatter then pairs template placeholders with arguments strictly by position (JsonLogMessageFormatter.cs).

The Microsoft.Extensions.Logging contract is that placeholders are resolved by name against the state key/value pairs; nothing guarantees that state enumeration order matches placeholder order. The most prominent violator ships in ASP.NET Core itself: HostingRequestStartingLog enumerates its state as Protocol, Method, ContentType, ContentLength, Scheme, Host, PathBase, Path, QueryString, while its template is:

Request starting {Protocol} {Method} {Scheme}://{Host}{PathBase}{Path}{QueryString} - {ContentType} {ContentLength}

So every Request starting log line of every ASP.NET Core app running on Lambda with JSON log format is silently garbled from the third placeholder on.

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

Template placeholders resolved by name, as with every other Microsoft.Extensions.Logging sink:

{
    "message": "Request starting HTTP/1.1 DELETE https://api.example.com/events/123?preserve=true - application/json 0",
    "Method": "DELETE",
    "Scheme": "https",
    "Host": "api.example.com",
    "Path": "/events/123",
    "QueryString": "?preserve=true",
    "ContentType": "application/json",
    "ContentLength": 0
}

Current Behavior

Actual CloudWatch log record (values anonymized). Note Scheme holding the content type, Host holding the content length, Path holding the host, ContentType holding the path, etc.:

{
    "timestamp": "2026-07-04T22:43:57.529Z",
    "level": "Information",
    "requestId": "188cbe50-087d-4465-acf4-d4a6067ef0da",
    "message": "Request starting {Protocol} DELETE application/json://0httpsapi.example.com - /events/123 ?preserve=true",
    "Method": "DELETE",
    "Scheme": "application/json",
    "Host": 0,
    "PathBase": "https",
    "Path": "api.example.com",
    "QueryString": "",
    "ContentType": "/events/123",
    "ContentLength": "?preserve=true"
}

Each placeholder received the state value at the same index instead of the value with the matching name ({Scheme} ← ContentType, {Host} ← ContentLength, {PathBase} ← Scheme, ...). The rendered message is garbled the same way.

Reproduction Steps

Minimal ASP.NET Core app:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddAWSLambdaHosting(LambdaEventSource.RestApi);
builder.Logging.ClearProviders();
builder.Logging.AddLambdaLogger();
var app = builder.Build();
app.MapGet("/", () => "ok");
app.Run();

Deploy behind API Gateway with:

LoggingConfig:
  LogFormat: JSON

Invoke any endpoint and inspect the Request starting record in CloudWatch: the Scheme, Host, PathBase, Path, QueryString, ContentType and ContentLength properties are shifted as shown above.

Possible Solution

Either:

• In LambdaILogger (JSON branch): parse the placeholder names from {OriginalFormat} and emit the arguments in placeholder order, resolving each one by key against the state; or
• In JsonLogMessageFormatter: when arguments come from an ILogger state, match them to placeholders by name instead of by position.

Additional Information/Context

Any ILogger event whose state enumeration order differs from its template placeholder order is affected — ASP.NET Core hosting logs are just the guaranteed-out-of-the-box case. Logs written through the standard LoggerExtensions/LoggerMessage paths happen to be unaffected because FormattedLogValues keeps both orders aligned, which is probably why this went unnoticed.

AWS .NET SDK and/or Package version used

Amazon.Lambda.AspNetCoreServer 10.1.1
Amazon.Lambda.AspNetCoreServer.Hosting 2.1.0
Amazon.Lambda.Logging.AspNetCore 5.0.0
Amazon.Lambda.Core 3.1.0

Targeted .NET Platform

.NET 10 (managed dotnet10 runtime)

Operating System and version

Amazon Linux 2023 (Lambda managed runtime)

[madmox]

For what it's worth, here is the approach we use in a custom ILoggerProvider to work around this. The same logic could slot into the JSON branch of LambdaILogger in Amazon.Lambda.Logging.AspNetCore, replacing the current "collect state values in enumeration order" loop: parse the placeholder names from {OriginalFormat}, then emit the arguments in placeholder order, resolving each one by key against the state.

private static bool TryBuildParameterizedLog(object state, out string template, out object?[] arguments)
{
    template = null;
    arguments = null;

    if (state is not IReadOnlyList<KeyValuePair<string, object?>> properties)
        return false;

    string originalFormat = null;
    foreach (var property in properties)
        if (property is { Key: "{OriginalFormat}", Value: string value })
            originalFormat = value;

    if (originalFormat is null)
        return false;

    string[] placeholders = ParsePlaceholderNames(originalFormat);

    // No placeholders, or positional template ("{0}", "{1}"...): state order already
    // matches placeholder order, pass through unchanged.
    if (placeholders.Length == 0 || placeholders.All(n => n.All(char.IsDigit)))
    {
        template = originalFormat;
        arguments = properties
            .Where(p => p.Key != "{OriginalFormat}")
            .Select(p => p.Value)
            .ToArray();
        return true;
    }

    var valuesByName = new Dictionary<string, object?>(properties.Count);
    foreach (var property in properties)
        if (property.Key != "{OriginalFormat}")
            valuesByName[property.Key] = property.Value;

    // JsonLogMessageFormatter pairs placeholders with arguments strictly by position:
    // an unresolved name yields a null argument, which keeps its slot so subsequent
    // placeholders stay aligned.
    var ordered = new object?[placeholders.Length];
    for (int i = 0; i < placeholders.Length; i++)
    {
        string name = placeholders[i];
        if (!valuesByName.TryGetValue(name, out ordered[i]) && (name.StartsWith('@') || name.StartsWith('$')))
            valuesByName.TryGetValue(name[1..], out ordered[i]);
    }

    template = originalFormat;
    arguments = ordered;
    return true;
}

private static string[] ParsePlaceholderNames(string template)
{
    var names = new List<string>();
    int index = 0;

    while (index < template.Length)
    {
        if (template[index] != '{') { index++; continue; }

        // "{{" is an escaped brace, not a placeholder
        if (index + 1 < template.Length && template[index + 1] == '{') { index += 2; continue; }

        int closing = template.IndexOf('}', index + 1);
        if (closing < 0) break;

        string name = template[(index + 1)..closing];

        // Strip alignment ("{Name,10}") and format ("{Name:N0}") specifiers
        int delimiter = name.IndexOfAny([',', ':']);
        if (delimiter >= 0) name = name[..delimiter];

        if (name.Length > 0) names.Add(name);
        index = closing + 1;
    }

    return names.ToArray();
}

Notes:

• Resolving by exact key first, then falling back to the @/$-stripped name, covers destructuring hints regardless of whether the state keys carry the prefix.
• In production code, ParsePlaceholderNames results should be cached per template string (call sites reuse the same templates), with a size cap for dynamically-built templates.
• Events whose state enumeration order already matches the template — the common FormattedLogValues case — produce the exact same output as today, so this is behavior-preserving except for the currently-garbled events.
• Snippet uses modern C# for brevity; trivial to downlevel if the target still includes netstandard2.0.

We implemented this as a workaround in our codebase (not yet deployed): the transformation logic is unit-tested, including against the HostingRequestStartingLog state/template shapes, but I haven't validated the end-to-end output on a deployed function yet.

[normj]

Thanks for reporting the issue and I'm investigating the issue.