Masstransit: cfg.UseRetry(); with the new Lambda-based retry policy configurator throw exceptions

Created on 27 Jan 2017  路  8Comments  路  Source: MassTransit/MassTransit

Getting exceptions that the RetryPolicy cannot be null, after i Upgraded to MT 3.5.4.

The service bus was not properly configured:
[Failure] RetryPolicy must not be null

```c#
private static IBusControl CreateIBusControl(Container container)
{
var configurator = container.GetInstance();

        var bus = configurator
            .CreateBus((cfg, host) =>
            {
                cfg.ReceiveEndpoint<CollectCommand>(c =>
                {
                    c.LoadFrom(container);
                });
                // works
                cfg.UseRetry(Retry.Exponential(3, TimeSpan.FromSeconds(5), TimeSpan.FromMinutes(2), TimeSpan.FromSeconds(5))); 
                // doesn't work
                cfg.UseRetry(r => Retry.Exponential(3, TimeSpan.FromSeconds(5), TimeSpan.FromMinutes(2), TimeSpan.FromSeconds(5))); 
            })
            .ConfigureAwait(false)
            .GetAwaiter()
            .GetResult();
        return bus;
    }
Using this configurator helper class:
```c#
        public async Task<IBusControl> CreateBus(Action<IBusFactoryConfigurator, IHost> registrationAction = null, Action<IRetryConfigurator> retryGlobalPolicy = null)
        {
            var t = await Task.Run(() =>
            {
                var connUri = new Uri(Configuration.ConnectionUri);
                var bus = Bus.Factory.CreateUsingAzureServiceBus(cfg =>
                {
                    var host = cfg.Host(connUri, hst =>
                    {
                        hst.TokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider(Configuration.Login, Configuration.Password);
                    });

                    registrationAction?.Invoke(cfg, host);
                    cfg.UseJsonSerializer();
                });
                return bus;
            });
            return t;
        }

Most helpful comment

Ah, so simple a miss and course it works now when actually using the lambda! (using r.* not Retry.*) Much gratitude for the effort and time used to answer this issue!

All 8 comments

You should be configuring retry within the receive endpoint, or before the receive endpoint is declared. Or matters in configuration.

I'll check into why the bus level retry policy is saying it is null, shouldn't be an issue but I'll check.

Also, make sure the right namespaces are included, there were issues previously.

Just verified your example above works for me, initial + 3 retries.

Thanks for the fast reply! I will create a new slim project and see if I can replicate the issue there. It's weird that not using the lambda on the same code line makes it work. Might got something to do with async/await in combination with a lambda. I'll try around some more and get back on monday. Thanks, once again!

Why are you doing all this async trickery to create the bus? That seems unnecessary, and all that GetAwaiter, etc. is just creating who knows what kind of complexity on the stack.

Yes it was unnecessary. I made a clean project that demonstrate this problem with minimum async/await implementation- only bus.GetSendEndpointAsync() because thats the contract in MassTransit core.

I created an AzureSB and included the connectionstring to it temporarily for making it easier to just hit F5 and run. Here is the repo: https://github.com/rille111/Samples.Azure
Program.cs:56 it works with the old Retry() setup, where using row 54 throw exceptions.

Don't seem like Async/Await produces the exception what I can see ..

Pull request submitted, short answer, you weren't using the lambda, you were just doing essentially a no-op in the method.

Ah, so simple a miss and course it works now when actually using the lambda! (using r.* not Retry.*) Much gratitude for the effort and time used to answer this issue!

Was this page helpful?
0 / 5 - 0 ratings