ReceiverSettingsValidation and poison queue fallback logic might need a closer look

[danielmarbach]

Describe the suggested improvement

ASQ validates early on the settings for the poison queue

NServiceBus.AzureStorageQueues/src/Transport/AzureStorageQueueTransport.cs

Line 146 in a7de739

ValidateReceiversSettings(receiversSettings);

but later then has sane fallback strategies to discover sensible defaults

https://github.com/Particular/NServiceBus.AzureStorageQueues/blob/a7de739961f1a87552a78f4c2bee37eefe30b76d/src/Transport/AzureStorageQueueTransport.cs#L231C1-L233

those sensible defaults though are not using the Core error queue fallbacks by leveraging https://github.com/Particular/NServiceBus/blob/master/src/NServiceBus.Core/Recoverability/Faults/ErrorQueueSettings.cs#L19. Furthermore, from a lower level transport seam implementation each receiver is allowed to have their own error queue but the fallback logic does a FirstOrDefault which could lead to inconsistent or surprising behavior.

Additional Context

No response

[jpalac]

@danielmarbach Is this issue still relevant, and if so would you be able to update the description to include some more details such as the scenario(s) where this causes problems for users?

[danielmarbach]

@jpalac I don't remember much more than what is already written in the issue. This is a minor thing and could be done in any updates to the transport or be deferred for a long time. Currently I'm not aware it has caused any bugs, but in theory it could, especially with raw transport usage scenarios.