Bsft.Messaging.EFCore.Postgres 2.2.0

Bsft.Messaging.EFCore.Postgres

The PostgreSQL wake-up for the Bsft.Messaging EF Core outbox. A commit that wrote outbox rows announces itself with pg_notify; a listening worker hears it and drains the outbox at once, instead of the dispatcher waiting out its poll interval.

It is an optimisation and nothing more. The polling dispatcher stays registered and stays the guarantee: a notification that is never sent, never received, or lost with the connection it was travelling on costs one poll interval and no message. The lease, the retry schedule and the dead-letter policy are untouched — the drain a notification triggers is the dispatcher's own IOutboxProcessor.ProcessOnceAsync, so two instances woken by the same notification share the backlog exactly as two polling instances do.

Install

dotnet add package Bsft.Messaging.EFCore.Postgres

Requires Bsft.Messaging.EFCore and Npgsql.EntityFrameworkCore.PostgreSQL. The listener needs no schema of its own: LISTEN/NOTIFY is a server feature, so there is no migration to add.

Register

services.AddBsftMessaging(configuration, options => options.AddEvent<OrderPlaced>("orders.placed.v1"));
services.AddBsftMessagingEFCore<AppDbContext>();
services.AddBsftMessagingEFCorePostgres<AppDbContext>(configuration);

services.AddDbContext<AppDbContext>((sp, options) => options
    .UseNpgsql(connectionString)
    .AddInterceptors(
        sp.GetRequiredService<OutboxInterceptor>(),
        sp.GetRequiredService<OutboxNotifyInterceptor>()));

Call it alongside AddBsftMessagingEFCore, never instead of it: that call registers the dispatcher that delivers. The order the two interceptors are added in does not matter — the notify interceptor reads the change tracker after the save has completed, not the buffer the outbox interceptor drains.

Once it is wired, a longer Bsft:Messaging:Outbox:PollInterval costs nothing in the common case: the poll becomes the safety net rather than the delivery path. Switching polling off is not an option the framework offers, and deliberately so.

Configure

Bound from Bsft:Messaging:Postgres when the IConfiguration overload is used, and validated on start.

Extend

The listening session behind the worker is internal. It is one Npgsql connection that subscribes, waits and calls back; everything with a decision in it — when to reconnect, what to drain, what to log — is in the worker, which is what the tests exercise.

How it fits together

A notification is sent from the context that wrote the rows, which puts it on the same connection and therefore inside the same transaction whenever the caller opened one. PostgreSQL delivers a notification raised inside a transaction when that transaction commits and discards it when it rolls back, so a listener is never woken for rows that do not exist. Outside a transaction the rows are already written by the time the announcement goes out. Either way the wake-up cannot run ahead of what it is about.

The payload is empty on purpose: a notification says only that the outbox has something in it, and the lease decides what. Carrying row identities would put a second, weaker source of truth beside the lease.

See docs/messaging.md for the outbox itself, and ADR-0005 for why the drain kernel is still the integration-event one.