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)
@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
, withu
the user config ands
the “server” config. Will do that for all fields that need checking (since some don’t, like DeliverSubject, etc…).