DEV Community: EladSer

Don't mutate CommandText in an EF Core interceptor (a mistake I shipped)

EladSer — Sat, 13 Jun 2026 07:58:25 +0000

For about a year, my debugging tool crashed the instant anyone pointed it at SQLite. I had no idea, because I only ever ran it against SQL Server. Nobody opened an issue either, which tells you roughly how many people were using it. Here's the bug, because it's an easy one to ship and I doubt I'm alone.

The tool records the SQL that EF Core runs (among other things) and shows it in a dashboard. To do that it uses a DbCommandInterceptor, and I wanted each query's execution time. The way I got it was bad enough that I'll just show you:

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

On the way in, glue a comment with an id and a timestamp onto the SQL. On the way out, in ReaderExecuted, parse that comment back off the command text and subtract to get the elapsed time. A little correlation system, smuggled through the query string.

Yeah.

The first problem is that this changes the SQL you send to the database. Every query left with a /* ... */ tail on it. SQL Server shrugs and runs it, which is the whole reason I never noticed, but now the database's own query logging is full of my garbage and I'm writing to something that isn't mine to write to.

The second problem is the one that actually broke. Rewriting CommandText after the command has run, while its reader is still open, throws on SQLite:

System.InvalidOperationException: An open reader is associated with this
command. Close it before changing the CommandText property.

SQLite in local dev is completely normal. So instead of a dashboard, those people got an exception thrown from inside the tool that was supposed to be helping them debug. Great look.

Now the part that stings. I built that whole id-in-a-comment contraption to carry one number from ReaderExecuting to ReaderExecuted. I never needed to. ReaderExecuted already hands you the duration, and the command, and everything else:

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

CommandExecutedEventData.Duration is a TimeSpan that EF measured for me. The command is right there too. There was nothing to correlate, because both halves of what I wanted live in the same callback. I'd written a solution to a problem the API had already solved, and that solution happened to corrupt SQL and crash SQLite on its way past.

If you genuinely do need to carry state from executing to executed (something that's only available before the command runs, say), there's a stable handle for that too. eventData.CommandId is the same Guid across both calls. Key your own dictionary off it and leave the SQL alone:

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

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

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

The command object is for reading. Whatever you want to stash, stash it on your side.

I rebuilt the tool around the boring one-liner and shipped 2.0. MIT, .NET 8/9/10, two lines to wire up, then you open /_debug and get your requests, the SQL with real parameter values, logs, exceptions, and an N+1 nag when one request fires the same query over and over. Demo gif and setup in the readme: https://github.com/eladser/AspNetDebugDashboard

If you write interceptors, go look at yours and make sure they're not doing something clever to the command text. Mine looked fine for a year.

I built a local Network tab for LLM calls (with evals), in .NET

EladSer — Sun, 07 Jun 2026 10:47:13 +0000

When you build something on top of an LLM, you mostly fly blind. You send a prompt, you get an answer, and the interesting parts are invisible: the exact text that went to the model after your code stitched it together, what that one call cost, how long it took, whether it called a tool, and whether a prompt or model change quietly made the answers worse.

In the browser you'd open the Network tab. For AI calls there wasn't a good local equivalent, especially in .NET. So I built one: Seerlens.

What it is

One command, and a local dashboard shows every LLM call your app makes, live:

dotnet tool install -g Seerlens
seerlens   # dashboard at http://localhost:5005

Then point your app at it. In .NET you wrap the IChatClient you already use:

using Seerlens.Sdk;

SeerlensTrace.Configure("http://localhost:5005");
IChatClient client = baseClient.UseSeerlens();

Every call through client shows up: the prompt, the completion, tokens, cost in dollars, latency, and any tool calls. It's local-first, SQLite, no signup, no cloud.

It's built on the OpenTelemetry GenAI conventions, so it isn't .NET-only (any OTLP app works, and there are small SDKs for Python and JS). But I lead with .NET on purpose.

Why .NET

The .NET AI stack grew up fast: Microsoft.Extensions.AI, Semantic Kernel, the Aspire dashboard. It traces calls well. What it doesn't do is judge whether the answer was any good, or turn tokens into a budget you can act on. The Python world has Langfuse, Phoenix, Promptfoo, Braintrust for that. .NET had basically nothing. That gap is the whole reason Seerlens exists.

The part I actually care about: evals

Tracing gets you in the door. The thing that separates "called an API once" from "ran AI for real" is catching quality regressions. You write a small golden set, score answers against it, and watch the trend over time.

You can gate CI on it:

seerlens eval support --min 0.8 --baseline .seerlens/support.base

That exits non-zero if the score drops below a floor, or regresses too far from a saved baseline. So a model swap that quietly drops answer quality becomes a red check on the PR, not a surprise in production.

There are three scorers: keyword (offline), llm-judge (grade against a rubric), and one I'm happy with, agent: it gives the model a case's tools, lets it actually call them, and scores whether it reached for the right tools in the right order. "Right answer, wrong tool path" shows up as a lower score.

What it's not

Worth being upfront, because it shapes whether it fits you. It's single-user and local: no auth, no shared dashboard. SQLite is fine for the dev loop, not a production firehose. The agent scorer uses tools you declare with canned results, it doesn't execute your real tools. And cost is only as fresh as the price table (which you can override). For a team watching production traffic, a deployed platform is the right call. This is the local dev-loop tool.

Try it

MIT licensed, on GitHub, NuGet, PyPI and npm.

Repo: https://github.com/eladser/seerlens
dotnet tool install -g Seerlens / pip install seerlens / npm install seerlens

It's a side project I've been building in the open, so I'd genuinely like feedback on where it falls short.