Requests a sweep without waiting for it — call it after the transaction resolves. Coalesced: at most one sweep runs and one follow-up waits. Never throws; a no-op once the outbox is closing.
Deletes sent and discarded rows older than retainSentMs, at most
purgeBatch per status per store. One deadline, relay.sweepDeadlineMs,
bounds the whole run across every store; a store call still running at
the deadline rejects the purge, and rows already deleted stay deleted.
The number of rows deleted
Releases a failed row: retry returns it to pending; discard
settles it without publishing. Takes effect for the relay at its next lap.
An operator capability: the application gates the route that calls it.
The row (envelope) id
retry or discard
Optionaloptions: { tenantId?: string }
The tenant, required with per-tenant stores
Runs (or joins) a sweep and resolves with its result.
The sweep result
Writes an integration event as an outbox row inside the caller's
transaction, through the unit of work the caller's transaction(...)
handed it. Every refusal is a rejected promise, so the business write
rolls back with it.
Caller obligation: the selected store must read the database scope
belongs to. A per-tenant store for another tenant, or a store bound to
another database.<name>, receives a row its relay never sees.
The caller's unit of work
The integration-event contract
The event payload
Optionalinput: OutboxWriteInput
Metadata, publish options and tenant
The envelope id
The transactional outbox, registered under
CAPABILITIES.OUTBOX(outbox.<name>for a named messaging instance).The promise. At-least-once delivery of every committed row. At most one relay holds a row's claim, provided relays' wall clocks agree within
relay.maxClockSkewMs. A relay starts publishing only while its claim has room for the publish, status write and skew. Per-key order among first publishes across any number of relays assumes rows commit in write order and writers' clocks agree. Delivery order is the broker's; consumers compareaggregateVersion. A pause after the fence check or a publish the broker accepts after abandonment can cause repeats, including out of order. Never exactly once: repeats carry the same envelope and de-duplication id.Since
0.9.0