Some correlated KestrelEventSource logs are called with different ExecutionContexts breaking ActivityIds #26560
Labels
affected-few
This issue impacts only small number of customers
area-networking
Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions
enhancement
This issue represents an ask for new feature or an enhancement to an existing one
feature-kestrel
severity-minor
This label is used by an internal tool
Milestone
@MihaZupan brought it to our attention that some of Kestrel's EventSource Start/Stop logs are called with different ExecutionContexts even though they're supposed to be correlated.
This is generally (if not always) caused by dispatching using ThreadPool.UnsafeQueueUserWorkItem() and not manually capturing and restoring the ExecutionContext before emitting the next EventSource log. This breaks the automatic ActivityId tracking that the EventSource Start/Stop convention is supposed to give us.
In particular, Kestrel's ConnectionQueuedStart/Stop logs and Kestrel's HTTP/2+HTTP/3 RequestQueuedStart/Stop logs are emmitted without the same execution context.
aspnetcore/src/Servers/Kestrel/Core/src/Internal/ConnectionDispatcher.cs
Lines 64 to 66 in 96c082f
aspnetcore/src/Servers/Kestrel/Core/src/Internal/Http2/Http2Connection.cs
Lines 1064 to 1066 in 96c082f
aspnetcore/src/Servers/Kestrel/Core/src/Internal/Http3/Http3Connection.cs
Lines 246 to 247 in 96c082f
This results in ConnectionQueuedStop and RequestQueuedStop logs without any ActivityId at all. Below I've included all the
EventWrittenEventArgs
emmitted by the KestrelEventSource logger when making an HTTP/2 GET request against Kestrel's sample app. They're collapsed because it's over 600 lines, but you can see the lack of ActivityIds for these logs.EventWrittenEventArgs as JSON
The text was updated successfully, but these errors were encountered: