Evaluate if is it worth exposing the message visibility timeout setting

[mauroservienti]

As part of #998 it was necessary to expose to users the message visibility timeout as a configurable setting. We made the decision to expose that as a setting bound to the message-driven pub/sub compatibility mode in the SqsSubscriptionMigrationModeSettings class:

NServiceBus.AmazonSQS/src/NServiceBus.Transport.SQS/Configure/SqsSubscriptionMigrationModeSettings.cs

Lines 52 to 63 in 8be2241

	public SubscriptionMigrationModeSettings MessageVisibilityTimeout(int timeoutInSeconds)
	{
	//HINT: See https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html
	if (timeoutInSeconds < 0 || timeoutInSeconds > TimeSpan.FromHours(12).TotalSeconds)
	{
	throw new ArgumentOutOfRangeException(nameof(timeoutInSeconds));
	}
	settings.Set(SettingsKeys.MessageVisibilityTimeout, timeoutInSeconds);
	return this;
	}

Due to the way SQS works (message pickup + visibility timeout) there always is the possibility that, if message processing takes longer than the default (30") visibility timeout, it results in a duplicate message.

One option could be to expose the message visibility timeout as a transport setting and not only a message-driven pub/sub compatibility mode setting.

[jdaigle]

I think this is worth it: #2162

[mauroservienti]

Thanks for your input, @jdaigle. We discussed this in the past, and we were debating if it's better to have this one or #1003, which automatically extends the visibility timeout for message handling running longer than the default. Both have pros and cons. What is the scenario that makes you want to have control over the visibility timeout?

[jdaigle]

@mauroservienti The simplest scenario is where the default timeout of the queue isn’t sufficient (e.g. too low) and for whatever reason can’t be changed.

I can also imagine using this setting when creating the queue, and maybe updating the attributes for an existing queue.