When adding a consumer, clients should provide a name if neither name or durable is not supplied.

[scottf]

Overview

This applies to both legacy and simplification.

Considers the state of the server:

type ConsumerConfig struct {
    // Durable is deprecated. All consumers should have names, picked by clients.
    Durable         string          `json:"durable_name,omitempty"`
        ...

I'm assuming "picked by clients" intends either developer supplied or generated by the library.

Reminder

Server pre 2.9.0 does not accept a configuration name, but does generate one when the configuration is not durable.

Generate Consumer Name

The go implementation generates a consumer name the way the server does

func generateConsName() string {
    name := nuid.Next()
    sha := sha256.New()
    sha.Write([]byte(name))
    b := sha.Sum(nil)
    for i := 0; i < 8; i++ {
        b[i] = rdigits[int(b[i]%base)]
    }
    return string(b[:8])
}

Java and .net take the 10 sequence bytes from the global Nuid's nextNuid.

Clients and Tools

• [x] CLI @ripienaar
• [x] Go @piotrpio
• [x] Java @scottf https://github.com/nats-io/nats.java/pull/923
• [ ] JavaScript @aricart
• [x] .Net @scottf https://github.com/nats-io/nats.net/pull/787
• [ ] C @levb
• [ ] Python @wallyqs
• [ ] Ruby @wallyqs
• [ ] Rust @Jarema @caspervonb

Other Tasks

• [ ] docs.nats.io updated @bruth
• [ ] 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.

[aricart]

@Jarema the requirement on the client to generate a name actually is burdensome somewhere. In the case of javascript it would require having some sha, which will mean a library dependency in some environments creating additional burden on the client. I think the correct thing to do is simply put the name the user gave, or allow the server to generate the name it wants with the constraints in length/format that it should.

[scottf]

I agree that this requirement isn't really useful. The server already would make the name if not supplied. Also, I use the 10 sequence bytes of the nuid, I do not digest the nuid

[wallyqs]

If cannot have a similar version like the server it is fine to just use the nuid, or generally just a random unique 8 char string for the ephemeral consumers case should be enough I think. No need to have a sha256 dep, it just can't be a truncated nuid since the suffix is what changes sequentially most of the time.

[scottf]

We are fine with that the name is generated differently on each client. We just want to understand where the requirement to generate the name on the client comes from.

[aricart]

Again the point is that if the server wants to control the names that are generated to have some format it should do that, nuid, or some truncated or hashed nuid, etc, that choice can be made at server level. otherwise the name should be whatever the user says.

[bruth]

Apologizes for injecting myself (I don't have the context of the conversation leading up to this). But.. my understanding is that the distinction of "ephemeral-ness" is now solely on the inactivity threshold. The name is more or less irrelevant except for distinguishing consumers when the distinction is needed (monitoring, debugging, durable lookups).

Personally, I don't see the point of the client needing to generate a name if the server can do it, and in a consistent form. On the durable side of things, the convention is for the user to set a name (since it will need to be looked up/rebound multiple times) which implies no activity threshold by default.