Creating a subscription with a consumer config change against an existing consumer

[scottf]

Overview

Based on conversation, the expectation is choice #4

Reject any attempt to create a subscription against an existing durable unless the subscription is a bind subscription or the provided consumer config matches exactly.

Clients and Tools

• Go @wallyqs
• Java @scottf
• JavaScript @aricart
• .Net @ColinSullivan1 @scottf
• C @kozlovic
• Python @wallyqs
• Rust @Jarema

Other Tasks

• docs.nats.io updated
• Update ADR to Implemented
• Update client features spreadsheet

Client authors please update with your progress. If you open issues in your own repositories as a result of this request, please link them to this one by pasting the issue URL in a comment or main issue description.

Issue History

Currently when creating a subscription in the Java and .NET client, if a user offers a consumer configuration change against an existing consumer, that change is ignored and there is no attempt to update the consumer.

Is this the desired behavior when the offered config does not match the config from the server? Some options include:

1. Ignore silently as described
2. Check the configs for equality and attempt to update the consumer, passing on any update errors to the user
3. Check the configs for equality and reject any changes without trying to update
4. Reject any attempt to create a subscription against an existing durable unless the subscription is a bind subscription
5. Ask server to do update and see if it fails.

[ripienaar]

Consumers cannot be updated. The only property that’s mutable is the deliver subject.

[scottf]

Consumers cannot be updated. The only property that’s mutable is the deliver subject.

That should probably rule out option 2.

[ripienaar]

Iirc the server treats consumer updates as idempotent. So if a update happens that isn’t identical (other than subject) it would cause an error. Essentially we have 3 now.

I need to double check this is from memory how it works

[kozlovic]

Remember that the library will more often do a lookup first. So the issue that @scottf you are reporting is likely that the "subscribe" call does not match what the consumer config is already is, and you should be testing that what config is passed (when it is passed, that's the key) to the "subscribe" call matches what is found in the consumer config object returned by the lookup. Some background: nats-io/nats.go#803

[scottf]

@kozlovic Yes, this is the "subscribe" call does not match the existing consumer.
As a team we agreed to gather consensus before implementing client features. The behavior implemented in 803 was not, AFAIK discussed with the team. I made this issue for the purpose of gaining consensus before I learned about 803.
@ColinSullivan1 @aricart @wallyqs @ripienaar @variadico please vote on 1, 3 or 4

1. Ignore silently as described
2. [Ruled Out] Check the configs for equality and attempt to update the consumer, passing on any update errors to the user
3. Check the configs for equality and reject any changes without trying to update
4. Reject any attempt to create a subscription against an existing durable unless the subscription is a bind subscription

[scottf]

My order of preference is 4, 3, 1. 4 would essentially prefer (but not require) that durable consumers should be made ahead of time, before subscriptions, which seems like a reasonable idea.

[bruth]

Now that a handful consumer options can be updated, I presume it is safer/simpler to have the server reject the update?

[marthaCP]

This will be addressed with JS Simplification - this is the problem JS Simpl will fix.