"filter_subject" option is somehow added to the consumer option even when I don't specify it

[Nowogrodzki]

Hello, I came up with a strange problem, In the project I'm using Nats 2.10 and I want to take advantage of the filter_subjects option.
I have a stream foo-bar-baz that contains subjects like *.*.*.foo-bar-baz.*.*. Currently, I have around 1k subjects and I want to filter them out, but before I released the new option I checked the current consumer configuration and I found that the filter_subject(the single one) option already exists even if I didn't specify it in the code. After releasing the new option I'm facing the error consumer with multiple subject filters cannot use subject-based API and it is caused by the fact the filter_subject option already exists. Is there any default behavior that adds this option? I checked almost every piece of code and I'm pretty sure that I'm not adding it anywhere

[Jarema]

Hey!

Can you show us some code snippet how are you updating the consumer?
The error you mentioned happens if subject based API is used to create multiple filter consumer.
You also should not pass both single filter and multiple filters.

[Nowogrodzki]

For test purposes, I just removed the current consumer, restarted the app, and let the consumer subscribe once again(after restart consumer should subscribe with the filter_subjects option.
I don't add a filter_subject(a single one) in the consumer configuration, it somehow appears when the consumer subscribes to the stream

[Nowogrodzki]

Subscription snippet

function snippet (subject, options) { // options contains "config: { filter_subjects: subjects }" where "subjects" is an array of strings 
    const defaultHandlerOptions: Partial<ConsumerOpts> = {
    queue,
    mack: true,
    config: {
      flow_control: false, 
      deliver_policy: DeliverPolicy.New,
      ack_wait: 60_000_000_000,
      max_ack_pending: 64,
      max_deliver: 60, 
      durable_name: config.defaultDurableName,
      deliver_subject: createInbox(),
    },
  };

  const subscription = await jetStreamClient.subscribe(subject, {
    ...defaultHandlerOptions,
    ...options,
    config: {
      ...defaultHandlerOptions.config,
      ...options?.config,
    },
  });
  
}

[Nowogrodzki]

Consumer configuration returned from nats-cli for stream foo-bar-baz

Configuration:

    Name: consumer
    Delivery Subject: foo
      Filter Subject: *.*.*.foo-bar-baz.*.*
      Deliver Policy: New
          Ack Policy: Explicit
            Ack Wait: 1m0s
       Replay Policy: Instant
  Maximum Deliveries: 60
     Max Ack Pending: 64
        Flow Control: false

[aricart]

When you do a subscribe and don't specify a filter subject, the filter subject is set to the subject specified in the subscribe. Note that the subject specified on subscribe is used to locate the stream. I have verified that this is the case in go as it is in JavaScript. The NATS cli can leave it blank because it is tied to the stream when created, so the filter is optional there. The reasoning behind this on the clients is that if the stream is modified, the client will start receiving messages on subjects that it can possibly not handle properly. If the filter is provided it must match the subject or be a wildcard.

With that aside, the API for subscribe is a bit challenging because it auto-creates a consumer. So for example in your code above, you use an inbox which will change every time that the consumer is run.

A better alternative is to create the consumer as you want it, using the JSM apis ((await nc.jetstreamManager()).consumers.add()) and then use the new consumer API (js.consumers.get()) and consume messages from that. You have more fine grain control of your intention, and separate the logic of the consumer creation from it's use.