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
Is your feature request related to a problem? Please describe.
I had a requirement where I needed to log multiple operations in a single event, but outside of AspNetCore. To make that work, I created a "wrapper" similar to the middleware in this library, relying on DiagnosticContext in the implementation, and on IDiagnosticContext in the consumer logging code.
However, I quickly realized that unit testing the behavior while using the concrete DiagnosticContext was very challenging. I was not able to force Set calls in the context while being able to persist the state in my unit test. I believe this is due to the AsyncLocal usage that happens internally, which disallows passing any information "from the outside" to the current context.
Describe the solution you'd like
I'd like either an interface that exposes the "collection side" of DiagnosticContext, so that I can rely on it instead of the concrete class in my implementation and be able to test or, alternatively, some sort of simpler implementation for the class tailored for testing, which would allow me to call Set from the outside and see those reflected in the context after BeginCollection is called.
I believe the former would be simpler to do, however.
Describe alternatives you've considered
I was unable to unit test the behavior around Set. I could've extracted an interface for that myself but decided against it for simplicity, then ended up testing the rest of the behavior without validating the added properties.
Additional context
I think IDiagnosticContext has broader usage than just AspNetCore, so perhaps it would be a good idea to move it away from this package and leave only the actual middleware here.
Additionally, I wish I actually didn't have to rely on IDiagnosticContext at all for the log aggregation behavior. More here (related) #222
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
I had a requirement where I needed to log multiple operations in a single event, but outside of AspNetCore. To make that work, I created a "wrapper" similar to the middleware in this library, relying on
DiagnosticContext
in the implementation, and onIDiagnosticContext
in the consumer logging code.However, I quickly realized that unit testing the behavior while using the concrete
DiagnosticContext
was very challenging. I was not able to forceSet
calls in the context while being able to persist the state in my unit test. I believe this is due to theAsyncLocal
usage that happens internally, which disallows passing any information "from the outside" to the current context.Describe the solution you'd like
I'd like either an interface that exposes the "collection side" of
DiagnosticContext
, so that I can rely on it instead of the concrete class in my implementation and be able to test or, alternatively, some sort of simpler implementation for the class tailored for testing, which would allow me to callSet
from the outside and see those reflected in the context afterBeginCollection
is called.I believe the former would be simpler to do, however.
Describe alternatives you've considered
I was unable to unit test the behavior around
Set
. I could've extracted an interface for that myself but decided against it for simplicity, then ended up testing the rest of the behavior without validating the added properties.Additional context
I think
IDiagnosticContext
has broader usage than just AspNetCore, so perhaps it would be a good idea to move it away from this package and leave only the actual middleware here.Additionally, I wish I actually didn't have to rely on
IDiagnosticContext
at all for the log aggregation behavior. More here (related) #222The text was updated successfully, but these errors were encountered: