Problem
PerRequestLogBuffer is a public extension point in Microsoft.Extensions.Diagnostics.Buffering, but the available implementation is internal to ASP.NET Core and tied to IHttpContextAccessor. Applications that want to buffer logs for another operation boundary—such as AWS Lambda invocation or a queue message—must implement operation-scoped storage and rule matching themselves.
Some existing implementation pieces are not reusable from application code. For example, LogBufferingFilterRuleSelector is internal. BufferedLogRecord is public and abstract, but there is no public concrete implementation or factory, so custom buffers must also provide their own record type.
Proposal
Could the buffering APIs expose reusable building blocks for custom per-operation implementations? Useful pieces might include public rule-selection and buffered-record creation APIs, or a base implementation that accepts an application-defined operation context and lifecycle.
The goal is to let non-ASP.NET applications reuse the framework's buffering behavior without depending on ASP.NET Core or copying its internal implementation.
Problem
PerRequestLogBufferis a public extension point inMicrosoft.Extensions.Diagnostics.Buffering, but the available implementation is internal to ASP.NET Core and tied toIHttpContextAccessor. Applications that want to buffer logs for another operation boundary—such as AWS Lambda invocation or a queue message—must implement operation-scoped storage and rule matching themselves.Some existing implementation pieces are not reusable from application code. For example,
LogBufferingFilterRuleSelectoris internal.BufferedLogRecordis public and abstract, but there is no public concrete implementation or factory, so custom buffers must also provide their own record type.Proposal
Could the buffering APIs expose reusable building blocks for custom per-operation implementations? Useful pieces might include public rule-selection and buffered-record creation APIs, or a base implementation that accepts an application-defined operation context and lifecycle.
The goal is to let non-ASP.NET applications reuse the framework's buffering behavior without depending on ASP.NET Core or copying its internal implementation.