Issues reported in Go JetStream simplification

[aricart]

Overview

This is actually just a list of issues reported on JetStream simplification on the Go client, most may be Go specific, but take a look if you are doing something similar that may require some fix.

[These were extracted from internal client-dev channel notified by @piotrpio ]

• New jetstream interface: Problem using private inbox (was: How to get subjects in a stream?) nats.go#1307 - probably only in my client, but I forgot to include option to filter results of ListStreams and StreamNames based on subject

• New jetstream interface, consumer.Info() returns error consumer instance not yet created nats.go#1305 - this is an issue with creating ordered consumer - what I did at first is I only created the actual consumer on the server once any method to receive messages was invoked (Consume, Fetch etc). This caused consumer.Info() to return error if called right after after stream.OrderedConsumer() . I am changing this to create consumer as soon as OrderedConsumer() is invoked

• User complained about being able to easily get stream name by subject, without having to call ListStreams - I added a StreamNameBySubject method on JetStreamContext

• Carefully consider the right naming for your methods to create/update the consumer, as in the next server release (
  @Tomasz
  please confirm) there will be option to specify operation field when creating consumer (create/update ) to include proper server side validation (e.g. for create return error if you were to update existing consumer. This is the reason my method is now called CreateOrUpdateConsumer

• There seemed to be confusion around why consume.Stop is not removing the consumer (as when unsubscribing in old API), so that may have to be well documented: New jetstream interface unclear how now to do something similar to Unsubscribe an ephemeral consumer nats.go#1304

• https://github.com/nats-io/nats.go/pull/1322/files - this is a PR which makes js simplification use custom inbox prefix configured on nats.Conn - I missed that completely

• new jetstream interface does not allow an OrderedConsumer to be HeadersOnly. Why? nats.go#1323 - this is about missing HeadersOnly field on OrderedConsumerConfig -
  @Alberto
  I think you may be missing this one as well
  #1323 new jetstream interface does not allow an OrderedConsumer to be HeadersOnly. Why?

Clients and Tools

• Go @piotrpio
• Java @scottf
• JavaScript @aricart
• .Net @scottf
• 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]

• For javascript, JSM streams list allows for filter to be specified.
• In javascript getting info on an ordered consumer that doesn't exist will realize the consumer
• In Javascript stopping a consumer doesn't delete it - destroy does.
• Prefixes for JetStream can be specified on both the js and jsm contexts
• [FIXED] ability to specify headers only in an ordered consumer

[aricart]

@Jarema I know that 2.10.x will have the ability to identify whether the intent of the operation is create/update, can you please put a pointer to the PR so we can ADR it

[scottf]

For java/.net

• JSManagement already provides to get stream list with filter.
• Ordered consumer is not implemented yet, but consumer info cannot be called without a consumer and consumer.info isn't exposed unless there is a consumer, so not sure how this applies.
• used the name CreateOrUpdateConsumer
• "stop" drains / unsubscribe, so an ephemeral will no longer have interest and be destroyed. Durable will do durable.
• creating simplification contexts allows providing JetStreamOptions, which support custom jetreams prefixes and domains. Connection options provide the ability to replace the default inbox prefix.
• There is one ConsumerConfiguration object, which already supports headers only. The same object is used in simplification or not simplification since it's the exact same code underneath. There is no requirement to have a different consumer configuration under simplification.

[Jarema]

Here is the PR: nats-io/nats-server#4217

Before 2.10, you would need to do the same as old Go client did: First call info, them create / update or not.
After 2.10, you can skip this check, saving a lot of resources on the server side (and have less race'y behaviour)

[scottf]

Here is the PR: nats-io/nats-server#4217

Before 2.10, you would need to do the same as old Go client did: First call info, them create / update or not. After 2.10, you can skip this check, saving a lot of resources on the server side (and have less race'y behaviour)

Is there an work issue created for this functionality?