Nservicebus: Throwing exception when user is mixing autosubscribe with explicit subscription

[WojcikMike]

Currently it is perfectly fine to have Autosubscribe feature enabled and calling Subscribe<Event>()
in the same endpoint. NSB in such case detects duplicate subscription and make sure that subscriber will get event only one time. As a result of discussion with @weralabaj and @SzymonPobiega #3274 it might be a good idea to detect such situation and throw an exception suggesting user to disable Autosubscribe if he wants to use explicit subscriptions.

Who's affected

Users using Pub/sub capabilities of NSB. As currently we are fixing the situation without letting users know, introducing such feature could make some applications to fail at start-up.

This feature will allow users to better understand the platform. But this is a change in behavior comparing to NSB Version 5.

[SzymonPobiega]

So you are saying that currently when you have autosubscribe enabled and you subscribe, we'll detect that duplicate behind the scenes and the manual subscribe will be essentionally a NOOP?

And the proposal here is to throw in Subscribe when autosubscribe is enabled?

[WojcikMike]

Yes :+1: so that you get notification with my thumb

[andreasohlund]

And the proposal here is to throw in Subscribe when autosubscribe is enabled?

I like @johnsimons proposal (can't find the link) to have the subscribe api be wrapped by the autosubscribe

Ie:

config.DisableAutoSubscribe(s=>s.Subscribe<MyEvent>())

we can then take this further and make unsubscribe be based in the return value:

var subscriptions = config.DisableAutoSubscribe(s=>s.Subscribe<MyEvent>())

subscriptions.Unsubscribe<MyEvent>()
subscriptions.Unsubscribe<SomEventIDidntSubscribeTo>() //boom

@Particular/nservicebus-maintainers thoughts?

[andreasohlund]

This would solve https://github.com/Particular/PlatformDevelopment/issues/281

[SzymonPobiega]

When wouldsubscriptions.Unsubscribe() be allowed? During whole endpoint lifetime or only during the startup phase? What does it add in terms of safety of unsubscribing?

I wonder if we are not mixing two different concepts in out handling of pub/sub. One is a persistent subscriptions that always exists and can never be removed. Making sure that subscription is in place is a deployment concern. The other is an ad-hoc expression of will to receive messages of a given type. The latter seems to me kind of niche scenario applicable probably in some smart client-based systems when we only want to receive messages when the application is running.

I believe there are two kinds of subscriptions

• Transient - the subscription is created when the bus starts and removed when it stops
• Persistent - the subscription is created during the deployment time and cannot be removed. When the bus starts, the subscriber can validate if proper configuration is in place. Otherwise it refuses to run.

[andreasohlund]

I believe there are two kinds of subscriptions

Transient - the subscription is created when the bus starts and removed when it stops
Persistent - the subscription is created during the deployment time and cannot be removed. When the bus starts, the subscriber can validate if proper configuration is in place. Otherwise it refuses to run.

I like it, but where do autosubscribe fit in? (since that's not happening at deployment time)

[WojcikMike]

It seems that autosubscribe in such scenario would be doing Transient subscriptions. So it's actually autosubscribe/autounsubscribe stuff for you.

I am still trying to think if there are scenarios to subscribe to an event only when certain criterias are met. But than it can be achieved by Sagas. I will keep thinking about it.

[andreasohlund]

Proposed API to fix this https://github.com/Particular/NServiceBus/issues/2318#issuecomment-303645101

[timbussmann]

I like the approach proposed in #2318, thoughts @WojcikMike ?

[timbussmann]

I think this proposal is invalid based on today's behavior. e.g. there are certain scenarios where explicit subscribes are required additionally/despite using autosubscribe. I think we should close this, thoughts?

[WojcikMike]

I am looking through the issues for the next enhancement released and found this one. Based on your 2 year old comment, I will close this issue @timbussmann @bording if you think that something have changed till that time, feel free to re-open