EF Core-Interceptoren: Warum SQL-Mutationen zu Debugging-Problemen führen

Ein Debugging-Tool, das SQL-Abfragen für EF Core aufzeichnete, scheiterte plötzlich bei SQLite-Nutzern. Der Grund war eine vermeintlich harmlose Mutation des Befehlstexts. Doch warum führte dieser Ansatz zu Datenbankabstürzen – und wie lässt sich das Problem eleganter lösen?

Der fatale Eingriff in den Befehlstext

Die Idee schien simpel: Um die Ausführungsdauer einer SQL-Abfrage in EF Core zu messen, sollte ein Kommentar mit einer eindeutigen ID und einem Zeitstempel an den Befehlstext angehängt werden. Der Code im Interceptor sah etwa so aus:

public override InterceptionResult<DbDataReader> ReaderExecuting(
    DbCommand command, 
    CommandEventData eventData, 
    InterceptionResult<DbDataReader> result)
{
    var id = Guid.NewGuid();
    command.CommandText += $" /* {id}:{DateTime.UtcNow.Ticks} */";
    return result;
}

Im Nachhinein wirkt diese Methode wie ein Selbstzweck. Doch damals schien sie praktikabel – bis die ersten Nutzer des Tools mit SQLite auf ein Problem stießen: Ein offener Reader blockierte die Mutation des Befehlstexts, was zu einer System.InvalidOperationException führte. Während SQL Server dies tolerierte, brach SQLite die Ausführung ab. Das Tool, das eigentlich helfen sollte, wurde selbst zum Fehlerverursacher.

Die versteckte Lösung: EF Core liefert die Dauer bereits mit

Doch das eigentliche Problem war noch grundlegender. Die gewählte Methode war nicht nur riskant, sondern auch überflüssig. Denn EF Core bietet bereits eine eingebaute Möglichkeit, die Ausführungsdauer zu erfassen – im CommandExecutedEventData-Parameter der ReaderExecuted-Methode:

public override DbDataReader ReaderExecuted(
    DbCommand command, 
    CommandExecutedEventData eventData, 
    DbDataReader result)
{
    Record(command.CommandText, eventData.Duration);
    return result;
}

Hier steht mit eventData.Duration eine TimeSpan-Instanz bereit, die die exakte Laufzeit der Abfrage enthält. Der Befehlstext selbst bleibt unverändert, und die Datenbank wird nicht mit irrelevanten Kommentaren belastet. Die ursprüngliche Idee, eine Korrelation über Kommentare zu realisieren, war damit obsolet – und führte gleichzeitig zu unerwünschten Nebeneffekten.

Saubere Alternativen: State-Handling ohne SQL-Manipulation

Doch was, wenn tatsächlich Zustandsinformationen zwischen den Phasen Executing und Executed übertragen werden müssen? Zum Beispiel, wenn vor der Ausführung bestimmte Metriken erfasst werden müssen, die erst nach dem Abschluss verfügbar sind. EF Core bietet dafür eine stabile Lösung: die CommandId. Dieser eindeutige Bezeichner bleibt über beide Interceptor-Methoden hinweg konsistent und kann als Schlüssel für einen eigenen State-Speicher dienen.

Ein Beispiel für einen sauberen Ansatz:

private readonly ConcurrentDictionary<Guid, MyState> _inflight = new();

public override InterceptionResult<DbDataReader> ReaderExecuting(
    DbCommand command, 
    CommandEventData eventData, 
    InterceptionResult<DbDataReader> result)
{
    _inflight[eventData.CommandId] = CaptureState();
    return result;
}

public override DbDataReader ReaderExecuted(
    DbCommand command, 
    CommandExecutedEventData eventData, 
    DbDataReader result)
{
    if (_inflight.TryRemove(eventData.CommandId, out var state))
    {
        ProcessMetrics(state, eventData.Duration);
    }
    return result;
}

Diese Methode vermeidet jede Manipulation des CommandText und nutzt stattdessen einen eigenen Speicher (ConcurrentDictionary), um den Zustand zwischen den Interceptor-Aufrufen zu übertragen. Die Datenbank bleibt unberührt, und SQLite- oder andere Datenbank-Implementierungen arbeiten zuverlässig.

Fazit: Interceptor-Logik sollte die Datenbank respektieren

Der Vorfall zeigt, wie schnell vermeintlich clevere Lösungen zu unerwarteten Problemen führen können. Im Nachhinein wirkt die ursprüngliche Idee mit SQL-Kommentaren wie ein unnötiger Umweg – besonders, da EF Core bereits die benötigten Daten direkt bereitstellt. Wer Interceptor-Logik schreibt, sollte daher stets prüfen, ob die gewählte Methode die Datenbank oder den Befehlstext unnötig verändert. Eine saubere Trennung zwischen Zustandsmanagement und SQL-Verarbeitung vermeidet nicht nur Fehler, sondern macht den Code auch wartbarer und zukunftssicher. Die aktuelle Version des Tools setzt nun auf die bewährte, minimale Lösung – und vermeidet damit künftige Stolperfallen.