I've been working to track down the origin of an unobserved task exception that was reported to us. Unfortunately the stack trace I have doesn't offer many clues, but this did lead me on a journey through the internals of Serilog.Sinks.PeriodicBatching, our most substantial dependency, and the very old, incrementally-built implementation there had a number of weaknesses that could explain the issue.
This led to a rewrite of PeriodicBatching using the primitives available in modern framework versions - good Task/async support everywhere, and System.Threading.Channels - and without the obscuring clutter of conditional code required to support now-obsolete platforms.
The new PeriodicBatching needs some solid dogfooding and downstream testing, so that's this PR :-)
There are no known breaking changes, but PeriodicBatchingdoes include breaking changes that may affect other sinks being used in the same apps (details here), hence a major version bump.
I've been working to track down the origin of an unobserved task exception that was reported to us. Unfortunately the stack trace I have doesn't offer many clues, but this did lead me on a journey through the internals of Serilog.Sinks.PeriodicBatching, our most substantial dependency, and the very old, incrementally-built implementation there had a number of weaknesses that could explain the issue.
This led to a rewrite of PeriodicBatching using the primitives available in modern framework versions - good
Task/asyncsupport everywhere, and System.Threading.Channels - and without the obscuring clutter of conditional code required to support now-obsolete platforms.The new PeriodicBatching needs some solid dogfooding and downstream testing, so that's this PR :-)
There are no known breaking changes, but PeriodicBatching does include breaking changes that may affect other sinks being used in the same apps (details here), hence a major version bump.
Fixes #205