Summary
Serilog 4.1 introduced two new sink-configuration methods — LoggerSinkConfiguration.FallbackChain(...) and LoggerSinkConfiguration.Fallible(...) — but neither can be called from appsettings.json / IConfiguration today. Attempting to use them produces SelfLog output along the lines of:
Unable to find a method called FallbackChain...
Why it doesn't work today
Both methods are instance methods on LoggerSinkConfiguration rather than extension methods, so they aren't picked up by the extension-method scanner in ConfigurationReader.FindConfigurationExtensionMethods. For instance methods, this package keeps a hand-maintained list of "surrogate" methods in SurrogateConfigurationMethods. Only Sink and Logger are listed for WriteTo today.
Proposed fix
Add surrogate signatures for the two new methods:
```csharp
static LoggerConfiguration FallbackChain(
LoggerSinkConfiguration loggerSinkConfiguration,
Action configureSink,
Action configureFallback,
Action[]? configureSubsequentFallbacks = null)
=> loggerSinkConfiguration.FallbackChain(
configureSink, configureFallback, configureSubsequentFallbacks ?? []);
static LoggerConfiguration Fallible(
LoggerSinkConfiguration loggerSinkConfiguration,
Action configureSink,
ILoggingFailureListener failureListener)
=> loggerSinkConfiguration.Fallible(configureSink, failureListener);
```
The rest of the plumbing is already in place: `Action` and `Action[]` argument binding already work (they're how `WriteTo.Async`, `WriteTo.Conditional`, and similar wrappers resolve).
Note on `params`
`FallbackChain`'s third parameter is `params Action[]`. Because `params` does not set `ParameterInfo.HasDefaultValue = true`, it isn't treated as omittable by `HasImplicitValueWhenNotSpecified` in `ConfigurationReader`. The surrogate explicitly uses `= null` to make it optional. This is the same underlying mechanical issue tracked in #441; a broader fix there would let the surrogate drop the `?? []` workaround, but the surrogates can ship independently.
Not applicable to `AuditTo`
`LoggerAuditSinkConfiguration` does not expose `FallbackChain` or `Fallible` in Serilog. Audit pipelines are intentionally fail-loudly, so silently rerouting to a fallback or swallowing failures through a listener would break the audit guarantee. Surrogates should not be added there.
Summary
Serilog 4.1 introduced two new sink-configuration methods —
LoggerSinkConfiguration.FallbackChain(...)andLoggerSinkConfiguration.Fallible(...)— but neither can be called fromappsettings.json/IConfigurationtoday. Attempting to use them producesSelfLogoutput along the lines of:Why it doesn't work today
Both methods are instance methods on
LoggerSinkConfigurationrather than extension methods, so they aren't picked up by the extension-method scanner inConfigurationReader.FindConfigurationExtensionMethods. For instance methods, this package keeps a hand-maintained list of "surrogate" methods inSurrogateConfigurationMethods. OnlySinkandLoggerare listed forWriteTotoday.Proposed fix
Add surrogate signatures for the two new methods:
```csharp
static LoggerConfiguration FallbackChain(
LoggerSinkConfiguration loggerSinkConfiguration,
Action configureSink,
Action configureFallback,
Action[]? configureSubsequentFallbacks = null)
=> loggerSinkConfiguration.FallbackChain(
configureSink, configureFallback, configureSubsequentFallbacks ?? []);
static LoggerConfiguration Fallible(
LoggerSinkConfiguration loggerSinkConfiguration,
Action configureSink,
ILoggingFailureListener failureListener)
=> loggerSinkConfiguration.Fallible(configureSink, failureListener);
```
The rest of the plumbing is already in place: `Action` and `Action[]` argument binding already work (they're how `WriteTo.Async`, `WriteTo.Conditional`, and similar wrappers resolve).
Note on `params`
`FallbackChain`'s third parameter is `params Action[]`. Because `params` does not set `ParameterInfo.HasDefaultValue = true`, it isn't treated as omittable by `HasImplicitValueWhenNotSpecified` in `ConfigurationReader`. The surrogate explicitly uses `= null` to make it optional. This is the same underlying mechanical issue tracked in #441; a broader fix there would let the surrogate drop the `?? []` workaround, but the surrogates can ship independently.
Not applicable to `AuditTo`
`LoggerAuditSinkConfiguration` does not expose `FallbackChain` or `Fallible` in Serilog. Audit pipelines are intentionally fail-loudly, so silently rerouting to a fallback or swallowing failures through a listener would break the audit guarantee. Surrogates should not be added there.