Severity: Warning
File: src/Servy.UI/Bootstrapping/AppBootstrapper.cs lines 288–291
Description:
OnExit disposes only SecureData. The DbContext owned by the bootstrapper — which wraps the SQLite connection (and with it, any pooled connection state, journaling, WAL writebacks the underlying provider manages) — is never disposed at process exit of either WPF app (Servy or Servy.Manager). On a graceful shutdown this is merely wasteful; on an abrupt exit after open connections it can leave the DB in a slightly dirty state that the next startup has to recover through journal replay.
public void OnExit(ExitEventArgs e)
{
SecureData?.Dispose();
// DbContext never disposed; any other IDisposables owned by the bootstrapper either
}
Suggested fix:
Dispose the DB context (and any other long-lived disposables the bootstrapper owns) explicitly, guarded so one failure doesn't skip the next:
public void OnExit(ExitEventArgs e)
{
TryDispose(() => DbContext?.Dispose(), nameof(DbContext));
TryDispose(() => SecureData?.Dispose(), nameof(SecureData));
}
private static void TryDispose(Action dispose, string name)
{
try { dispose(); }
catch (Exception ex) { Logger.Warn($"{name} disposal failed", ex); }
}
Also worth a quick audit of other composition-root-owned services (loggers with internal flush semantics, file watchers, etc.) to ensure they participate in the same shutdown sequence.
Severity: Warning
File:
src/Servy.UI/Bootstrapping/AppBootstrapper.cslines 288–291Description:
OnExitdisposes onlySecureData. TheDbContextowned by the bootstrapper — which wraps the SQLite connection (and with it, any pooled connection state, journaling, WAL writebacks the underlying provider manages) — is never disposed at process exit of either WPF app (Servy or Servy.Manager). On a graceful shutdown this is merely wasteful; on an abrupt exit after open connections it can leave the DB in a slightly dirty state that the next startup has to recover through journal replay.Suggested fix:
Dispose the DB context (and any other long-lived disposables the bootstrapper owns) explicitly, guarded so one failure doesn't skip the next:
Also worth a quick audit of other composition-root-owned services (loggers with internal flush semantics, file watchers, etc.) to ensure they participate in the same shutdown sequence.