Option to specify or check minimum server version on connection

[brigitops]

Proposed change

Simple really. There is extensive logic already to ensure minimum server version for specific features e.g. object store support. This is hidden from the client API, behind func (nc *Conn) serverMinVersion.

We would like to be able to check this so that we can fail fast on startup, if the server version is insufficent for a feature we may need. This is in a long running client application, and we may not use some features until after startup.

I suggest a new nats.Option on the connection object. For example, to require 2.11 or greater, simply add:

err = nats.Connect(url, nats.MinServerVersion(2, 11, 0))

alternatives

Another way this could be done, is to allow connections to specify the features they want, rather than the version itself:

err = nats.Connect(url, nats.RequireServerFeature(ExpectLastSequenceForSubject))

This would be a higher level capability this would add a lot of support burden on your side, as you'd have to itemize every new server feature and would get rather bloated. I'd really be fine with specifying a desired version explicitly, and figuring out what version I need.

Perhaps the nicest thing, is to allow both. Allow MinServerVersion but also have some helper methods for common features, e.g. object store, ExpectLastSequenceForSubject, pausing consumers, etc... Client writers can always specify the version directly if you don't provide the exact version they want.

Of course, we could just make serverMinVersion() public but IMHO the nats Option seems cleaner.

Use case

We make use of some features introduced for server 2.11, and want to fail fast on startup when deployed against an older server version.

We use for example the jetstream.WithExpectLastSequenceForSubject option as a concurrency control. This is an awesome feature, but it silently does the wrong thing in 2.10.x. I think simply because the related header is unknown and ignored on the older server. So then the expectation is against the wrong subject and can fail unexpectedly. The situation might be worse than th, it might accidentally succeed when it shouldn't.

That confused us for a hot minute! I could open a separate bug report to fix this specific instance? But even so, it'd be better for users if our client application just simply reports right away that it's on an incompatible version, rather than running against an old version until it hits the incompatibility. So, even if this specific case was handled more explicitly by NATS, I think I'd still like to check minimum server version on startup, so that we give immediate feedback.

Contribution

I would be comfortable contributing the proposed feature given advice on the alternatives above, but my presumption is that it's more of a core team thing, given it's the connection's public API which is quite prominent.

[ripienaar]

Unfortunately the server version the clients knows about is the one it is connected to, while the server features being supported is essentially down to whoever are the servers serving a stream - these could be different or even be in different clusters far away, even cross leaf nodes.

You make a API call to the meta leader to ask its level, this is safer except really over leafnodes. Alternative is do a info on your stream in question and look at the metadata it tells you at what server feature level that particular stream is running. This is safest.

[brigitops]

Unfortunately the server version the clients knows about is the one it is connected to, while the server features being supported is essentially down to whoever are the servers serving a stream - these could be different or even be in different clusters far away, even cross leaf nodes.

You make a API call to the meta leader to ask its level, this is safer except really over leafnodes. Alternative is do a info on your stream in question and look at the metadata it tells you at what server feature level that particular stream is running. This is safest.

That's very helpful, thank you.

Does this mean that there is a bug with serverMinVersion() as it already exists, particularly for checking to creating or binding an object or kv store?

Also, I think this could still remain a useful feature request, perhaps a helper method on the stream itself? The version parsing could still be reused from the nats package (nats.go)?

[ripienaar]

Does this mean that there is a bug with serverMinVersion() as it already exists, particularly for checking to creating or binding an object or kv store?

It's not really a bug it's just best we had - we had to assume the cluster is always at same level for that function. But since that function we added the API level work which is much better for JetStream features.

It's not much parsing as such, you just check the Metadata["_nats.level"] and there's the value. Personally dont think it's worth bloating the client for something that simple.

[brigitops]

I see, I wasn't aware of the API level feature until now!

I agree that _nats.level is easy to parse as it is simply a number -- no need to deal with semantic versioning -- and it is superior to parsing the version for the purpose described anyway as it the intended purpose.

This satisfies our own needs. Might still not be a bad idea to add 3 methods that retrieve the server set metadata fields to StreamInfo, even without any parsing so that it is easier for developers to discover that it is available to them for use? If the idea is to keep the client really streamlined, mentioning them in the comments on Metadata could still be helpful? That might have been enough for me to "discover" the capability.

However, that is only a small suggestion now. I am happy to close if you feel that is unnecessary work. Either way -- thanks again for your help!