Why can't i see my response data in my callback?

Question

we're evaluating nservicebus at my company for a rewrite of our sales process. we'll be using sagas and web api. we ran into a block handling responses on the client side. we're using Handling Responses on the Client Side for guidance.

from our client controller we have this code:

    [Route("CreateProduct")]
    public ActionResult CreateProduct()
    {
        ProductCreatedResponse message = null;
        var product = new TestProduct { Id = ObjectId.GenerateNewId().ToString() };
        var command = new StartProductCommand { ProductId = product.Id, ProductName = "Product1" };

        var sync = ServiceBus.Bus.Send("Io.Server." + command.ProductName, command)
            .Register(ar =>
            {
                var localResult = (CompletionResult)ar.AsyncState;
                message = (ProductCreatedResponse)localResult.Messages[0];

                ViewBag.ResponseText = message.Status;
            }, null);

        sync.AsyncWaitHandle.WaitOne();

        return View("Index");
    }

from our saga's handler we have this code:

    public void Handle(StartProductCommand message)
    {
        Data.ProductId = message.ProductId;
        Data.Status = "Product Created";

        var productCreatedResponse = new ProductCreatedResponse { Status = Data.Status };

        _bus.Reply(productCreatedResponse );
    }

localResult.Messages is null. what am i doing wrong?

score 1 · Accepted Answer · answered Apr 05 '15 at 05:33

Callbacks can only handle int or enums: http://docs.particular.net/nservicebus/messaging/handling-responses-on-the-client-side

Take also a look at the warning on the above page:

"If the server process returns multiple responses, NServiceBus cannot know which response message will be the last. To prevent memory leaks, the callback is invoked only for the first response. Callbacks won't survive a process restart (common scenarios are a crash or an IIS recycle) as they are held in memory, so they are less suitable for server-side development where fault-tolerance is required. In those cases, sagas are preferred."

I believe you have to use the Return(...) method rather than the Reply(...) for this to work as well. — Tyler Day, Apr 05 '15 at 17:08

score 0 · Answer 2 · answered Apr 07 '15 at 09:32

In your saga you should remove the _bus private property that as I suspect gets injected. You should inherit your saga from Saga< T > abstract class. This class contains the Bus public property that gets injected for you. To report partial saga progress you should use Bus.ReplyToOriginator method instead of _bus.Reply.

All this is fully described in docs, you might need to look in this section.

score 0 · Answer 3 · answered Apr 07 '15 at 13:12

i figured out the answer. stupid problem. the nuget packages for nservicebus were out of sync. wow!!! nservicebus is one of those few resources that's spread across multiple projects. i had v5.12 on my web host then i added an endpoint via nuget and that version was v5.2. they must have changed something with the serialization between versions. it's too easy to f that up. they should have a warning in the host console telling you you're versions are out of sync and need to update.

Why can't i see my response data in my callback?

3 Answers3