Open ramonsmits opened 7 years ago
I would expect the first to throw and the second to warn, not the other way round.
@ramonsmits @Scooletz in the FLR/SLR + Transaction Mode set to None what happens if in a saga I set a timeout?
For book-keeping, I'm referencing the public issue in Metrics repo : https://github.com/Particular/NServiceBus.Metrics/issues/74
If you specify immediate and delayed retry configuration but set transaction mode to None you get the following log entries.
Something similar was with performance counters. You could call the API to enable it, but if you try to enable performance counters on a send-only endpoint this is just ignored.
However, in the recent version of the extracted performance counters package these is now a startup check that prevents the endpoint from starting if it detects that the endpoint is a send-only endpoint.
The fact that immediate and delayed retry configuration is ignored to me seems a bit more worrisome then throwing an exception because performance counters do not make sense for send-only endpoints.
This behavior is strange as the least dangourous configuration conflict is processed as being very severe.
I think something similar is with property encryption. It makes no sense in enabling if we detect there are no messages at all with encrypted properties and then we just ignore.
How should features behave? My personal opinion is that we should always throw exceptions when we detect conflicts even if some can be safely ignored. To me it should never be ignored as it could indicate a deployment configuration error like missing messages and or handler assemblies but based on a lot of current behavior we are very open in accepting configuration conflicts but raise ERROR or WARN log entries.
// cc @Scooletz