feat: Add RoutingSlip extension for Wolverine

[nkz-soft]

I used the MT implementation of Routing Slip, but due to a licensing change I started looking for alternatives. This is a first draft of a Routing Slip implementation using a Wolverine extension. I’d appreciate a fresh look perhaps there’s a better way to implement it.

[jeremydmiller]

@nkz-soft Hey, it's gonna be a day or two before I get you any useful feedback, but I see you here.

[jeremydmiller]

@nkz-soft I'm trying to get this into 5.15 by the end of the day. 5.16 early next week at worst.

Sorry, this is about the worst we've ever done getting a PR done

[nkz-soft]

@jeremydmiller
I've put together a roadmap for the RoutingSlip implementation, marking off completed tasks. I'm a bit tied up right now, but I expect to wrap it up in a couple of weeks.

Implemented

• Routing slip model with TrackingNumber, CreateTimestamp, remaining activities, and execution log
• Sequential activity execution (next activity is dequeued and sent)
• Reverse-order compensation (last executed activity compensated first)
• Basic routing slip builder (AddActivity(name, destinationUri))
• Routing slip startup integration via UseRoutingSlip(...)
• Middleware-driven orchestration for execution and compensation success paths
• Failure handling hook with configurable policy override (RoutingSlipOptions.OverridePolicy)
• Default failure transition behavior that discards the failed envelope and triggers coordinator callbacks
• Activity failure event publication (RoutingSlipActivityFailed)
• Compensation failure event publication (RoutingSlipCompensationFailed)
• Serializable exception mapping (ExceptionInfo) including inner exceptions
• End-to-end tests for happy path, execution failure, compensation flow, compensation failure, and retry override

Needs To Be Done

• Activity arguments payload per itinerary step
• Global routing slip variables and variable mutation during execution
• Separate execute and compensate addresses per activity
• Full routing slip event model (completed, faulted, activity completed/faulted, compensation completed/failed, etc.)
• Subscription model for routing slip events (multiple subscribers, event filters, content options)
• Rich execution result semantics (e.g., complete with variables, revise itinerary, terminate, explicit fault outcomes)
• Compensation log data payload per executed activity (not just name/URI/execution id)
• Stronger fault metadata and correlation fields for observability/interoperability

[jeremydmiller]

@nkz-soft Hey, I think we need to have a conversation about this and where you want to go. I think I'm leaning toward not wanting to support this in Wolverine proper. Would you want to just keep this as a separate project where you have full control?

I don't really recall anyone else wanting a Routing Slip implementation in Wolverine. And all of this can be done more easily in my opinion through a Saga that manages the steps and workflow.

I'm concerned in a way because this code strikes me as the exact kind of highly abstracted framework code that ends up being hard to maintain over time.

[nkz-soft]

As I mentioned earlier, we worked with MassTransit's RoutingSlip on one of our projects and I thought it would be nice to implement something similar here. Currently, we're using Saga, so this is essentially my personal pet project. I'm willing to maintain and evolve it. I agree that the code is fairly abstract, but it's less abstract than MT's implementation.😄 I just wanted to maintain backward compatibility with MT as much as possible.

I don't see any problem with moving this to a separate project. It isn't currently tied to the core at all, and I hope everything I wanted can be implemented via the core abstractions.