You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Dec 18, 2018. It is now read-only.
After seeing HostingLogScope, I realized we need the equivalent for Kestrel connections.
11 of the 13 special log functions defined in KestrelTrace take the connect id as a logging parameter. Of the remaining 2, KestrelTrace.ApplicationErrorreally should log the connection id but doesn't. It would be far more elegant to create a logging scope that includes the connection id assuming that these can be nested. This will also prevent future oversights like the one in ApplicationError.
An added benefit is that we could lazily serialize the connection id like we do with the request id since we're not constantly passing a connection id string to logging methods. See #638
Note: we will have to be careful when logging outside of the connection's async loop (such as in callbacks on the libuv thread) since the AsyncLocal backing for the scope (I assume that what's being used) won't be available. In those cases I imagine we log connection id's like we do today, but check the loglevel before calling the log method so we don't have to serialize the connection id unnecessarily. That's assuming we can't delay the logging until we get back on the async loop.