Serverless Wolverine Gets a Transactional Outbox in Wolverine 6.51

Wolverine 6.51 adds the DurabilityMode.ServerlessWithOutbox mode, letting handlers running on Cloud Run, AWS Lambda or Azure Functions keep the transactional outbox without always-on background agents. An externally triggered durability pass recovers messages that failed to send, and push receivers accept broker deliveries over HTTP. It is a useful option for teams on tight serverless budgets.

Key points

• DurabilityMode.ServerlessWithOutbox arrives in Wolverine 6.51, dropping background agents while keeping the outbox.
• Outgoing messages are written to the outbox in the handler's transaction and sent before the request completes.
• Failed sends are recovered by a durability pass, run via host.RunDurabilityPassAsync() or MapWolverineDurabilityEndpoints().
• OutboxStaleTime defaults to 60 seconds in this mode, so a pass retries only rows older than that.
• MapWolverineDurabilityEndpoints() requires you to name an authorization policy or call AllowAnonymous() explicitly.
• Use MapWolverinePushReceiver() for generic HTTP push delivery and MapPubsubPushReceiver() for Google Pub/Sub push subscriptions.

Wolverine was built for long-running processes, so always-on background work such as node heartbeats, leader election and broker listeners fits poorly with request-scoped serverless functions. Wolverine 6.51 adds DurabilityMode.ServerlessWithOutbox, which drops those background processes while keeping the transactional outbox. Outgoing messages are saved in the same database transaction as the handler's data, sent before the request finishes, and deleted once the broker accepts them.

If a send fails, the row stays in the outbox until an externally triggered durability pass retries it. That pass also releases due scheduled messages and recovers unhandled inbox messages, and it runs within a bounded duration. You can trigger it from code, through an HTTP endpoint or from the command line. Incoming messages from cloud services can be delivered by push through Wolverine.HTTP, and Google Pub/Sub has a dedicated mapper. Recovery latency now equals your trigger interval, which is the trade-off to weigh.

Real-world use

• A budget-conscious Wolverine and Marten service on Cloud Run that consumes Pub/Sub messages.
• An AWS Lambda order-processing function that must commit database changes and publish events atomically.
• A scheduled Cloud Run Job or Kubernetes CronJob that periodically sends stranded outbox messages.

Why it matters

Teams running Wolverine on serverless platforms can keep transactional outbox guarantees without a long-running process. Recovery latency equals your durability pass interval, and push endpoints must be authorized explicitly.

Related stories

• Critter Stack in Review: message loss fixes, clean shutdown and multi-tenancyJXJasperFx (Critter Stack) Blog3 d ago
• CritterWatch 1.1 groups dead letters by failure cause and acts on each group at onceJXJasperFx (Critter Stack) Blog4 d ago
• Wolverine 6.52.0 adds named connections and timer agentsWOWolverine releasesOct 24