Repository navigation
Allow custom JsonSerializerOptions (and converters) in JsonLogMessageFormatter #2350
Description
Describe the feature
The JsonLogMessageFormatter introduced in Amazon.Lambda.RuntimeSupport 1.12.0 hardcodes its JsonSerializerOptions in the parameterless constructor:
// JsonLogMessageFormatter.cs
private readonly JsonSerializerOptions _jsonSerializationOptions;
public JsonLogMessageFormatter()
{
_jsonSerializationOptions = new JsonSerializerOptions
{
DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull,
WriteIndented = false
};
}There is currently no way for a customer to inject custom JsonSerializerOptions or register custom JsonConverters. The only documented customization path is to apply [JsonConverter(...)] attributes individually on every property of every type that may end up in a {@param} destructured log call.
Use Case
Many .NET codebases use third-party value types that have no public properties (so JsonSerializer.Serialize without converters produces empty {}) but provide official JsonConverters in companion packages. Examples:
- NodaTime (
Instant,LocalDate,LocalDateTime,Duration,Period...) - converters inNodaTime.Serialization.SystemTextJson - NetTopologySuite geographic types - converters in
NetTopologySuite.IO.GeoJSON4STJ - Domain primitive / value object libraries like Vogen, StronglyTypedId - generated converters
In our codebase, NodaTime is used pervasively across business entities and SQS messages. Whenever we want to use the new {@Object} destructuring syntax to log a complex object, NodaTime properties serialize as empty objects, which silently loses data:
// Current output for `_logger.LogInformation("Email queued {@Message}", sqsMessage)`:
{
"timestamp": "2026-04-29T10:00:00.000Z",
"level": "Information",
"requestId": "...",
"message": "Email queued {@Message}",
"Message": {
"To": "alice@example.com",
"EventDate": {}, // ← lost: should be "2026-04-29T10:00:00Z"
"TemplateKey": "ACCOUNT_CREATED"
}
}Annotating each property of every entity with a custom [JsonConverter] attribute is invasive, mixes serialization concerns with persistence/domain code, and is fragile (easy to forget on a new property - silent data loss).
Proposed Solution
Expose a constructor overload (or a factory hook) that accepts a custom JsonSerializerOptions instance. Three possible levels of API, in order of preference:
- Minimal: add a static
JsonLogMessageFormatter.ConfigureOptions(Action<JsonSerializerOptions>)method that the runtime applies after creating its default options. Optionally also support a declarative form via anAWS_LAMBDA_LOG_FORMATTER_OPTIONS_CONFIGURATORenvironment variable pointing to aType::Method, mirroring how[LambdaSerializer]attribute already lets users plug a custom serializer. - DI-based: allow consumers to register a
JsonSerializerOptions(or anIJsonSerializerOptionsProvider) in DI; the runtime support reads it on first log call. - Subclass-friendly: change
_jsonSerializationOptionstoprotected, add a virtualCreateJsonSerializerOptions()method, allow subclassingJsonLogMessageFormatterand selecting it via env var or DI.
Option 1 is the least invasive and matches how Amazon.Lambda.Serialization.SystemTextJson.SourceGeneratorLambdaJsonSerializer<T> already lets customers swap the serializer.
Other Information
Alternatives considered
- Annotating every domain property with
[JsonConverter]: works but invasive, fragile, mixes concerns. - Avoiding
{@Object}on objects containing custom types: works but defeats much of the structured-logging value. - Pre-serializing in user code with
JsonSerializer.Serialize(value, customOptions)then logging as a string: loses the "queryable hierarchical fields" benefit on the CloudWatch Logs Insights side. - Switching to a third-party logger (Serilog, NLog): works but requires customers to leave the AWS-recommended path and re-implement
requestId/traceIdenrichment.
Additional context
- Affected source file:
Libraries/src/Amazon.Lambda.RuntimeSupport/Helpers/Logging/JsonLogMessageFormatter.cs - Related issue: Lambda Structured Logging Support #1747 (closed, parent feature for structured logging)
- Documentation: AWS .NET dev blog post on structured logging doesn't mention this customization path.
Adding this hook would close a real gap for any codebase using third-party value types with companion JsonConverters, without affecting the default behavior.
Acknowledgements
- I may be able to implement this feature request
- This feature might incur a breaking change
AWS .NET SDK and/or Package version used
Amazon.Lambda.RuntimeSupport: 1.12.0+ (provided by the managed runtime; source inspected onmasterbranch as of issue submission)Amazon.Lambda.Core: 2.4.0+Amazon.Lambda.Logging.AspNetCore: 5.0.0+
Targeted .NET Platform
.NET 10 (net10.0), running on the AWS Lambda managed dotnet10 runtime. The same limitation applies on net8.0 / dotnet8.
Operating System and version
AWS Lambda managed runtime (Amazon Linux 2023, x86_64). Reproducible identically on arm64. Local repro on Windows 11 / .NET 10 SDK.
Activity
GarrettBeatty commentedon Apr 30, 2026
Thanks for opening the issue. Feel free to contribute PR that can be reviewed by the team.
logical-intent commentedon May 10, 2026
This issue also affects AOT-compiled lambda projects.
If the logger would or could use the
SourceGeneratorLambdaJsonSerializerthat we pass toLambdaBootstrapBuilder.Create(...), it would be able to support structured logging of custom classes by the simple addition of one JsonSerializable attribute (per custom class).Today with the existing code, only the type name is printed.
The only workaround I found that flows through to Logs Insights in a usable way is to bypass the logging system entirely and use a
Console.WriteLine(JsonSerializer.Serialize(myCustomTypeObject, MyLambdaSerializerContext.Default.MyCustomType))and switch the lambda logging from "JSON" to "Text" mode. It's a kludge but I'll take it. (With a side-note that the currently published Powertools AOT logging example produces trim warnings with .NET 10, so that's not a viable alternative workaround either.)normj commentedon May 13, 2026
Let met take a crack at adding a
ConfigureStructuredLoggermethod toAmazon.Lambda.Core.LambdaLoggerthat would allow you passing in your own instance ofJsonSerializerOptions.madmox commentedon May 13, 2026
I would have loved to contribute a PR on this, but after looking more closely at the existing codebase I realize I lack the broader perspective needed to propose a solid implementation that covers all possible use cases. I wouldn't want to introduce a half-baked solution that misses edge cases or conflicts with the existing serialization pipeline.
I'll leave it to the maintainers or someone with deeper familiarity with the internals. Happy to help test or provide feedback on any proposed approach though.
normj commentedon May 13, 2026
Work between Amazon.Lambda.Core and Amazon.Lambda.RuntimeSupport is tricky because Amazon.Lambda.RuntimeSupport has a dependency on Amazon.Lambda.Core but since Amazon.Lambda.Core is brought in via the deployment bundle and Amazon.Lambda.RuntimeSupport is built into the managed runtime you can't guarantee you will be working with the version of Amazon.Lambda.Core you expect in Amazon.Lambda.RuntimeSupport. So you have to be extra defensive for missing types and methods. It is a pain and one we can't easily rollback if we make mistakes. I appreciate the effort but I think in this case it is best if I take lead on the code.
I'll ping when I have the PR out so you can give feedback on the public API and when the PR is done it will go out as a preview. In preview you can test using the executable programming model. I would appreciate any feedback during preview when I could still make changes.
normj commentedon May 18, 2026
PR #2383 is out to allow customizing the
JsonSerializerOptionsused for serializing the message parameters.normj commentedon May 18, 2026
Version
3.1.0of Amazon.Lambda.Core is out which has theLambdaLogger.ConfigureStructuredLoggingAPI which is currently in preview till the managed runtime gets updated. Till then you can use the new API when you deploy as a executable and include the latest versions ofAmazon.Lambda.CoreandAmazon.Lambda.RuntimeSupport.madmox commentedon Sep 1, 2026
Feedback on the deployed state of
ConfigureStructuredLogging, since the 2026-07-29 release notes say it "has been deployed to the managed runtime": it does not appear to be effective on the managed runtime yet, at least for class-library functions.Setup: .NET 10 class-library function on the managed
dotnet10runtime, eu-west-3, runtime versiondotnet:10.mainline.v43(ARN...:runtime:fe3aeb65c42423af6d5d92aa7c69504ad9216c72e3d6529ce5db3931f8e1a61d),Amazon.Lambda.Core3.3.0 in the deployment bundle, JSON log format. At startup we callLambdaLogger.ConfigureStructuredLoggingwithJsonSerializerOptionscarrying the NodaTime converters.Observed in CloudWatch: a destructured
{@ScheduledDate}(NodaTime.Instant) still renders as"ScheduledDate":{}. The override never reaches the formatter. The rendered message text shows the correct value (ToString()path), and plain POCOs destructure fine, so only the converter registration is missing.Control experiment: the exact same call against the
Amazon.Lambda.RuntimeSupport2.2.0 NuGet package (instantiatingJsonLogMessageFormatterdirectly) works: the override is applied and theInstantserializes as"2026-09-01T15:40:00Z". So the application side is fine; theRuntimeSupportbuild embedded in the managed runtime seems to predate the feature, or the class-library path doesn't wire the callback (the preview-phase note said testing was possible with the executable model).Happy to run any diagnostic you'd find useful on our side.
Remove investigation folder from PR (#2350)
normj commentedon Sep 24, 2026
@madmox I have reproduced your issue and looking into what is going on.
Fix ConfigureStructuredLogging options dropped due to duplicate forma…
Refactor shared JsonLogMessageFormatter creation into Initialize (#2350)
Address Copilot review: isolate callback-mutating test, use invariant…
Fix ConfigureStructuredLogging options dropped due to duplicate forma…
github-actions commentedon Sep 25, 2026
Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.
normj commentedon Sep 25, 2026
@madmox Sorry didn't mean to close the issue.
The fix has been released to NuGet which won't help the managed runtime but I have also pushed the change over to the Lambda team who will pick up the fix as part of the next deployment. Let's leave the issue open till we have confirmed the fix in a deployment managed runtime.