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
When using Serilog.Sinks.Slack together with the latest version of Serilog.Sinks.PeriodicBatching the call to Serilog.Log.CloseAndFlush() will crash with a StackOverflowException because the SlackSinkDispose method will call Dispose on PeriodicBatchSink which in turn calls Dispose on SlackSink, causing an endless loop.
This issue was discovered while using the Sink in a .NET Framework application where transient dependencies have to be explicitly included and where the dependency was updated to the latest version.
From my research into how PeriodicBatching code works and how other Sinks handle this it seems that maybe SinkSlack should be split up so that it doesn't pass a reference to itself to PeriodicBatchingSink. But I'm not sure how this change would affect people who use this library today.
Here is the sample code I used to reproduce the issue:
Each class now has a single responsibility, making the code easier to understand, maintain, and test.
The SlackSink no longer directly manages both its disposal and that of its components. The components (like SlackClient and PeriodicBatchingSink) handle their own lifecycles independently, reducing the risk of recursive disposal calls.
The SlackMessageFormatter and SlackClient can be reused or tested independently, providing more flexibility in the codebase.
Simplified Debugging:
If a stack overflow or other issue does occur, it’s easier to isolate the problem to a specific component, as each class now handles a distinct part of the process.
This redesign should help eliminate the stack overflow problem while also improving the overall architecture and maintainability of your logging infrastructure.
The text was updated successfully, but these errors were encountered:
Hi there. Thank you so much for your detailed response and analysis. This issue has already been reported as #48, but I appreciate how detailed this is.
I have actually been working on a revamp of the whole project removing the dependency on Newtonsoft.Json entirely, along with the PeriodicBatchingSink - which is now part of the core Serilog.
With that being said, I'm still debating how to proceed with versioning. I'm of the opinion that I will release one more version to at least fix the issue reported here, and then release a new major version which does away with the above-mentioned dependencies while also ending support for .net standard 1.*
Thanks for the update! It’s exciting to hear about the revamp, especially dropping Newtonsoft.Json and integrating the PeriodicBatchingSink directly into Serilog—those changes are bound to streamline things.
I think your plan for versioning makes a lot of sense. Pushing out one last version to address the current issue before rolling out the major overhaul seems like a smart way to keep things stable for users while you work on the bigger improvements. And yeah, ending support for .NET Standard 1.* feels like the right move given where things are headed.
I’m really looking forward to seeing what you come up with next! If there’s anything else I can help with or test, just let me know.
bhavens17
pushed a commit
to bhavens17/serilog-sinks-slack
that referenced
this issue
Sep 23, 2024
When using
Serilog.Sinks.Slack
together with the latest version ofSerilog.Sinks.PeriodicBatching
the call toSerilog.Log.CloseAndFlush()
will crash with aStackOverflowException
because theSlackSink
Dispose
method will callDispose
onPeriodicBatchSink
which in turn callsDispose
onSlackSink
, causing an endless loop.This issue was discovered while using the Sink in a .NET Framework application where transient dependencies have to be explicitly included and where the dependency was updated to the latest version.
From my research into how
PeriodicBatching
code works and how other Sinks handle this it seems that maybeSinkSlack
should be split up so that it doesn't pass a reference to itself toPeriodicBatchingSink
. But I'm not sure how this change would affect people who use this library today.Here is the sample code I used to reproduce the issue:
Serilog.Sinks.Slack
version is 2.2.2.Serilog.Sinks.PeriodicBatching
version is 5.0.0A suggested solution would look something similar to the following code:
Benefits of the Redesign:
Each class now has a single responsibility, making the code easier to understand, maintain, and test.
The SlackSink no longer directly manages both its disposal and that of its components. The components (like SlackClient and PeriodicBatchingSink) handle their own lifecycles independently, reducing the risk of recursive disposal calls.
The SlackMessageFormatter and SlackClient can be reused or tested independently, providing more flexibility in the codebase.
Simplified Debugging:
If a stack overflow or other issue does occur, it’s easier to isolate the problem to a specific component, as each class now handles a distinct part of the process.
This redesign should help eliminate the stack overflow problem while also improving the overall architecture and maintainability of your logging infrastructure.
The text was updated successfully, but these errors were encountered: