Fix deleting durable subscriptions on unsubscribe

[afansv]

When the application wants to stop receiving messages on a durable subscription, it should close - but not unsubscribe - this subscription.

https://docs.nats.io/legacy/stan/intro/channels/subscriptions/durable

[AlexCuse]

Thanks for this. Need to dig around in the docs next week and confirm it's still desirable (linked page is for STAN) but I think it makes sense.

[AlexCuse]

Do you have an example use case in mind for including the topic in durable name / queue group calculations @afansv ?

[afansv]

Do you have an example use case in mind for including the topic in durable name / queue group calculations @afansv ?

No. it's actually pretty pointless.

[AlexCuse]

I could imagine a scheme where either maps to some portion of the topic to be honest @afansv just a little merge-shy without some example usage.

[AlexCuse]

I've been working on a unified watermill-nats that can connect in jetstream or nats-core mode, the jetstream example from there could probably be modified to perform durable provisioning needed and demonstrate alternate durable / queue group calculators https://github.com/AlexCuse/watermill-nats/blob/master/_examples/jetstream.go

The calculated durable name likely needs to be taken into account when deciding whether or not to unsubscribe as well (since it could be derived from the topic only by an alternate calculator). I can probably branch off yours and run with it if you don't have time @afansv , I see there are some conflicts to deal with as well.

[AlexCuse]

Not found any mention of unsubscribe usage relative to durable consumers in jetstream docs but did find this note in the nats client godoc that seems to suggest that only durables that are automatically created by the client would be deleted on unsubscribe, which may be desirable. https://github.com/nats-io/nats.go/blob/main/nats.go#L4286-L4295

// Unsubscribe will remove interest in the given subject.
//
// For a JetStream subscription, if the library has created the JetStream
// consumer, it will send a DeleteConsumer request to the server (if the
// unsubscribe itself was successful). If the delete operation fails, the
// error will be returned.
// If you do not wish the JetStream consumer to be automatically deleted,
// ensure that the consumer is not created by the library, which means
// create the consumer with AddConsumer and bind to this consumer (using
// the nats.Bind() option).

[AlexCuse]

I didn't have as much time as I'd like this week to test but I think I've seen enough that I do think we likely need this change.

Given how much surface area the jetstream configuration has it might make sense to remove to auto provision option and instead provide a way users can modify the SubscribeInitialize behavior more directly. Will see what I can do to polish this PR up over the next week if you aren't able. The main things I see as needed are deleting the comment that links to legacy nats-streaming-server docs and taking the calculated durable into account when deciding whether or not to unsubscribe.

[AlexCuse]

Durables and ephemeral behave exactly the same except that an ephemeral will be automatically cleaned up (deleted) after a period of inactivity, specifically when there are no subscriptions bound to the consumer. By default, durables will remain even when there are periods of inactivity (unless InactiveThreshold is set explicitly).

From here: https://docs.nats.io/nats-concepts/jetstream/consumers

This actually seems to suggest unsubscribing would be fine. What is the durable setup you are using that you've seen problems with on close/unsubscribe?

[roblaszczak]

@AlexCuse @afansv We are doing some tidings in Watermill repos.

What we want to do about this PR? Is it still relevant?