Users expect transport and errors settings to be configured while these are being ignored

[ramonsmits]

Some users try do to things like:

.UseNServiceBus(configuration =>
{
    var endpointConfiguration = configuration.AdvancedConfiguration;
    endpointConfiguration.License(NServiceBusLicense);
    endpointConfiguration.EnableInstallers();
    endpointConfiguration.SendFailedMessagesTo(errorQueueName);

    var transport = endpointConfiguration.UseTransport<AzureServiceBusTransport>();
    transport.ConnectionString(serviceBusNameSpaceFQDN);
    transport.CustomTokenCredential(new DefaultAzureCredential());

    var recoverability = endpointConfiguration.Recoverability();
    recoverability.Immediate(customizations: immediate => { mmediate.NumberOfRetries(3); });
    recoverability.Delayed(customizations: delayed => { delayed.NumberOfRetries(5).TimeIncrease(TimeSpan.FromSeconds(30)); });

    endpointConfiguration.LimitMessageProcessingConcurrencyTo(numberOfConsumers);

    // Disable the error queue to let NserviceBus native dead-lettering handle repeated failures:

    configuration.DoNotSendMessagesToErrorQueue();

    //@TODO: Add throttling behavior

})

The transport and concurrency limit settings are ignored but users are unaware of this. Same with DoNotSendMessagesToErrorQueue which overrides SendFailedMessagesTo. These conflicting settings should result in an endpoint not being able to start or even better. Such APIs should not even be available when using Azure Functions.

[SeanFeldman]

That'd be nice.

Regarding sending messages to the error queue, could be possible with middleware.

[mikeminutillo]

In the following PR we are detecting when someone uses APIs to configure the transport in ways that do not function correctly in a serverless context:

• https://github.com/Particular/NServiceBus.AzureFunctions.Worker.ServiceBus/pull/382

The documentation for DoNotSendMessagesToErrorQueue states

Disables moving messages to the error queue even if an error queue name is configured.

That seems to imply that you are supposed to be allowed to configure both by design.

[jpalac]

@ramonsmits given the above comment, is this issue still valid or can it be closed?

[ramonsmits]

No, from my pov the Roslyn analyzer is a workaround for a badly designed API. APIs that don't make sense in the context should not even be available.

Either a different endpointconfiguration should be used or the endpoint configuration should not provide these and expose such APIs differently