nats.go: Return error if actual consumer configuration is different

Feature Request

When creating subscriptions I can pass extra options, e.g.:

sub, err := js.PullSubscribe("TEST.*", "testing", nats.MaxDeliver(3))

The consumer is created in NATS if it didn’t exist yet:

$ nats con info TEST testing
Information for Consumer TEST > testing created 2021-08-17T11:37:10+02:00

Configuration:

        Durable Name: testing
           Pull Mode: true
      Filter Subject: TEST.*
         Deliver All: true
          Ack Policy: Explicit
            Ack Wait: 30s
       Replay Policy: Instant
  Maximum Deliveries: 3
     Max Ack Pending: 20,000
   Max Waiting Pulls: 512

State:
...

If I then change the options, e.g.:

sub, err := js.PullSubscribe("TEST.*", "testing", nats.MaxDeliver(5))

Then the new value is silently ignored and the consumer still has Maximum Deliveries: 3. The options seems to be used only when creating a new consumer, but ignored otherwise (some of them at least).

While it might not be feasible to transparently update the consumer, I would expect to get an error telling me that the requested options do not match the actual consumer configuration.

Use Case:

I can very easily imagine a situation where a developer changes the options (adds a new one, removes one, changes a value) thinking that it will work. For someone unfamiliar with NATS JS it’s not obvious that some consumer object exists in NATS itself and that these options are not just client-side connection options. It’s easy for the code to diverge from the actual configuration.

Proposed Change:

Compare the actual consumer configuration with the requested one an return an error if there’s a mismatch.

It seems that the existing configuration is already read (the info variable), so this shouldn’t affect performance.

Who Benefits From The Change(s)?

Unwitting developers trying to change the consumer configuration.

Alternative Approaches

Update the consumer configuration to match the requested one.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 18 (17 by maintainers)

Commits related to this issue

Most upvoted comments

@wallyqs Sorry, I was going to let you know that I started looking into this. My plan is to have a “checkConfig” function that will ignore user settings that are not set, and otherwise compare. For instance: u.AckWait > 0 && u.AckWait != s.AckWait, with u the user config and s the “server” config. Will do that for all fields that need checking (since some don’t, like DeliverSubject, etc…).