Closed jeremydmiller closed 1 month ago
I'll add in our use case for reference. We have an Azure Service Bus Topic with multiple subscriptions. All messages sent to the topic are of the same type. However, each subscription on the topic has a filter on it and we want individual handlers for each subscription. Currently, all of our handlers are called, regardless of which subscription the message arrives from.
@BrianVallelunga I think this is likely to slide to Wolverine 2.3, but I'm hoping to get that out this coming week anyway. And thanks for the input!
@BrianVallelunga Unsurprisingly, I think I need to punt this until 2.4 in the next couple weeks. I've done some preliminary work and investigation so far.
HandlerGraph
should stop using the ImHashMap of message type to HandlerChain and message type to IMessageHandler[StickyHandler("endpoint name")]
HandlerGraph.Compile()
needs to account for sticky endpoint to handler relationshipsHandlerGraph.HandlerFor()
methods need to assert there's only one per message type, and have an overload that takes in Endpoint
Endpoint
argument to IExecutorFactory
@BrianVallelunga Here's the first tranche of work: https://github.com/JasperFx/wolverine/tree/sticky-handlers
More to come, but this will make it into 3.0
Thanks for the update. I'm looking forward to trying this when 3.0 is out.
This comes up often enough it's time to do something about it.
Let's say that there's a use case for the exact same message & message type to be handled separately and in parallel with separate message handlers. Wolverine can't do that today because it combines the handler calls on one chain ( a vestigal tail feature left over from the FubuTransportation roots)
Build some kind of syntax that allows for the handlers to be split between different endpoints & separate routing