Sending request with IMessageHandlerContext?

[charlessolar]

Is there any breaking reason why currently we can't send a request while handling a message?
I was just upgrading my app and there are a couple of places that I've been sending requests inside a message handler using IBus and am wondering if maybe you guys forgot or if there is some reason I shouldn't do that.

[weralabaj]

@Volak can you share code you're using?

[charlessolar]

Sure this is what I am trying to do - basically when I receive an event I want to fire off some commands and make sure they are accepted (in my app all commands need a reply of basically accepted / rejected)

public async Task Handle(Measured e, IMessageHandlerContext ctx)
 {
     var stash = await _uow.For<Stash>().Get(e.StashId);

     // Get all analyzers for the measured value
     var analyzers = await _uow.Query<Network.Analyzer.Queries.AnalyzersForEventMetric, IAnalyzer>(q =>
            {
                q.StashId = e.StashId;
                q.EventMetric = e.Metric;
            });

        // Have all analyzers mark the measurement
       // might be many analyzers, split the workload among endpoints
        await analyzers.WhenAllAsync(analyzer =>
        {
            // extension method for sending a message and waiting for the result
            return ctx.Command<Commands.Mark>(x =>
            {
                x.TickId = GuidGenerator.GenerateTimeBasedGuid();
                x.StashId = e.StashId;
                x.AnalyzerId = analyzer.Id;
                x.Stamp = e.Timestamp;
                x.Tags = e.Tags;
                x.Metric = e.Metric;
                x.Value = e.Value;
            });

        });

    }

[danielmarbach]

Hi @Volak

We deprecated the callback support entirely inside the handler.

https://docs.particular.net/nservicebus/upgrades/5to6/callbacks

The callback API is available as NServiceBus.Callbacks as an internal package but only as an extension method on top of IMessageSession.

The reason being: We think it is a suboptimal design practice to couple a received message and hold up all the associated resources (including transactions etc.) to replies that are eventually never received from the receiving endpoints. If you need such a coordination we suggest you to use a coordinator saga which fans out to the analyzers and the analyzers can then simply reply to that command which gets routed back to the saga. This also allows you to add proper compensations, timeouts for SLA purposes and so on.

[weralabaj]

Daniel beat me up before I managed to respond, but generally he's right, in such a case we usually advise using saga or splitting sending and receving logic between separate handlers.

If you're not sure how to go about that we can schedule a call to discuss this in more detail.

[charlessolar]

@danielmarbach @weralabaj Thanks for the info - I've not used sagas before since my apps don't currently have long running logics but I understand a bit.

But I am not sure how I would fan out a command to all my different analyzers - since it seems I get the same IMessageHandlerContext?

[weralabaj]

@Volak Sounds a little bit like it could be an event and analyzers could be subscribers? If you want to keep a command then it might sense to have a dedicated command for each analyzer.

[charlessolar]

I think I have my head wrapped around this saga thing - instead of using my nice and easy extension method to wait for a reply inside a handler I can just use ctx.Send( Command ) and setup a default CommandSaga to wait for responses and react to failures or timeouts.

Going to close this for now - thanks!