Interceptors and SaveChanges Overrides for Auditing, Timestamps, Domain Events, and Outbox Hooks

Learning outcomes

ServiceHub now needs consistent audit timestamps and eventually reliable publication of domain events. Both are cross-cutting concerns around SaveChanges, but they have different durability requirements. A timestamp can be mutated before commands are generated; an email/Kafka/HTTP side effect must not be fired before the database commit and then assumed atomic. This lesson compares overrides, ISaveChangesInterceptor, and a transactional outbox hook.

1. Override or interceptor?

Choose the boundary matching ownership. A ServiceHub-specific invariant may belong in the domain/context; reusable audit instrumentation may fit an interceptor. Database-enforced invariants still belong in constraints/triggers where appropriate.

public override Task<int> SaveChangesAsync(    bool acceptAllChangesOnSuccess,    CancellationToken cancellationToken = default){    StampAuditMetadata();    return base.SaveChangesAsync(        acceptAllChangesOnSuccess,        cancellationToken);}

An override is appropriate when this behavior belongs specifically to ServiceHubContext. If both sync and async save APIs are exposed, keep their behavior consistent rather than accidentally stamping only one path.

2. Auditing with an interceptor: update metadata before commands are generated

public sealed class AuditSaveChangesInterceptor(TimeProvider clock)    : SaveChangesInterceptor{    public override InterceptionResult<int> SavingChanges(        DbContextEventData eventData,        InterceptionResult<int> result)    {        Stamp(eventData.Context);        return result;    }    public override ValueTask<InterceptionResult<int>> SavingChangesAsync(        DbContextEventData eventData,        InterceptionResult<int> result,        CancellationToken cancellationToken = default)    {        Stamp(eventData.Context);        return ValueTask.FromResult(result);    }    private void Stamp(DbContext? context)    {        if (context is null) return;        var now = clock.GetUtcNow().UtcDateTime;        foreach (var entry in context.ChangeTracker.Entries<WorkOrder>())        {            if (entry.State == EntityState.Added)                entry.Property("CreatedUtc").CurrentValue = now;        }    }}

This uses the existing Chapter 04 shadow CreatedUtc; no schema change is required. It does not authorize the write or advance the business Revision token automatically—those remain explicit domain/application responsibilities.

services.AddSingleton(TimeProvider.System);services.AddSingleton<AuditSaveChangesInterceptor>();services.AddDbContext<ServiceHubContext>((sp, options) =>    options        .UseSqlite(connectionString)        .AddInterceptors(sp.GetRequiredService<AuditSaveChangesInterceptor>()));

Interceptors are registered with context configuration. Keep stateful interceptor lifetime/thread-safety aligned with how contexts are created; a stateless singleton using thread-safe dependencies is different from an interceptor that accumulates per-save mutable state.

3. Deliberately wrong: publish external events inside SavingChanges

public override async ValueTask<InterceptionResult<int>> SavingChangesAsync(...){    await messageBus.PublishAsync(new WorkOrderChanged(...), cancellationToken);    return result;}

If the message succeeds and the database transaction later fails, consumers observe an event for data that never committed. If the database commits and the process crashes before publication, the event is lost. Retries can publish duplicates. An interceptor cannot turn two independent durable systems into one atomic transaction by wishful ordering.

4. Transactional outbox: make the database write atomic, dispatch later

The outbox pattern stores an event/message row in the same database transaction as the aggregate change. A separate dispatcher later publishes undelivered rows and marks them processed using an idempotent protocol. The outbox does not create exactly-once delivery; it creates a durable handoff that can be retried.

public sealed class OutboxMessage{    public Guid Id { get; init; }    public DateTime OccurredUtc { get; init; }    public string Type { get; init; } = null!;    public string PayloadJson { get; init; } = null!;    public DateTime? ProcessedUtc { get; set; }}

foreach (var order in db.ChangeTracker.Entries<WorkOrder>()         .Where(e => e.State == EntityState.Modified)){    db.Set<OutboxMessage>().Add(new OutboxMessage    {        Id = Guid.NewGuid(),        OccurredUtc = clock.GetUtcNow().UtcDateTime,        Type = "WorkOrderChanged",        PayloadJson = BuildMinimalOutboxPayload(order.Entity)    });}await db.SaveChangesAsync(ct); // aggregate + outbox rows share this SaveChanges transaction

For the hands-on lab, add an outbox_messages table in the disposable SQLite database via a reviewed migration such as AddOutboxLab. This is an explicit Chapter 12 lab evolution; do not hide it inside EnsureCreated.

5. Dispatch after commit with idempotency and observable state

var pending = await db.Set<OutboxMessage>()    .Where(x => x.ProcessedUtc == null)    .OrderBy(x => x.OccurredUtc)    .Take(100)    .ToListAsync(ct);foreach (var message in pending){    await publisher.PublishAsync(        message.Type,        message.PayloadJson,        idempotencyKey: message.Id.ToString(),        ct);    message.ProcessedUtc = clock.GetUtcNow().UtcDateTime;    await db.SaveChangesAsync(ct);}

A crash between publish and ProcessedUtc can cause redelivery, so the message ID must serve as an idempotency/deduplication key where the downstream contract allows it. Chapter 25 revisits production outbox architecture; here the goal is write-order correctness.

6. SavedChanges and SaveChangesFailed are observability/control hooks, not magic repair

public override int SavedChanges(SaveChangesCompletedEventData eventData, int result){    logger.LogInformation("SaveChanges committed {Rows} state entries", result);    return result;}public override void SaveChangesFailed(DbContextErrorEventData eventData){    logger.LogError(eventData.Exception, "SaveChanges failed for {ContextId}",        eventData.Context?.ContextId);}

Prefer Microsoft.Extensions.Logging/diagnostics for ordinary logs; interception is justified when the application must participate in or observe the save operation itself. Do not swallow an exception in the interceptor unless you are deliberately changing the operation contract and have exhaustive tests.

7. Test the ordering and failure cases

1. Reset SQLite and verify CreatedUtc is stamped for an Added work order by the interceptor.
2. Use a fake TimeProvider so timestamp assertions are deterministic.
3. Trigger a database constraint failure and verify SaveChangesFailed is observed while the database remains unchanged.
4. Create the disposable AddOutboxLab migration and inspect its SQL before applying.
5. Modify one work order and add one outbox row in the same SaveChanges call; inject a failure and prove neither commits.
6. Run the dispatcher with a fake publisher, crash after publish but before marking processed, rerun, and verify the idempotency key exposes duplicate delivery rather than hiding it.
7. Capture logs/traces for save start, command transaction, success/failure, and outbox processing.

8. Production judgment and bridge to Chapter 13

Keep SaveChanges interception small, deterministic, testable, and free of uncontrolled external I/O. Audit metadata may be a pre-save mutation; reliable integration messages need a database-backed outbox plus idempotent post-commit dispatch. Chapter 13 now focuses on the optimistic concurrency predicate already visible in ServiceHub writes: application-managed revisions, SQL Server rowversion, PostgreSQL xmin, and deterministic conflict resolution.

Authoritative references

• Interceptors - EF Core — SaveChanges interception and registration model.
• ISaveChangesInterceptor API — EF Core 10 save interception contract.
• Using Transactions - EF Core — atomic SaveChanges database transaction behavior.
• Logging and Diagnostics - EF Core — when to use logging/diagnostics versus interception.
• TimeProvider API — testable clock abstraction for deterministic timestamps.