JetStream - filtered consumer not unique on workqueue stream - queue consumers

I’m hitting a filtered consumer not unique on workqueue stream error when trying to setup a WorkQueue policy on a stream with load balanced consumers. I read the documentation a couple times but I guess there’s something I don’t get.

If I understand correctly, as per the docs on retention policy, it is clearly stated that:

The WorkQueuePolicy mode is a specialized mode where a message, once consumed and acknowledged, is discarded from the Stream. In this mode, there are a few limits on consumers. Inherently it's about 1 message to one consumer, this means you cannot have overlapping consumers defined on the Stream - needs unique filter subjects.

I tried the following options:

const natsSubscriptionOpts = consumerOpts();
natsSubscriptionOpts.ackExplicit();
natsSubscriptionOpts.queue('myqueue');
natsSubscriptionOpts.deliverTo('test.sub');

According to this issue response, you also have to set the durable name (which in my opinion goes against what the documentation says), but I also tried to set it with

natsSubscriptionOpts.durable('worker');

Anyway I always hit the same error once I try to span more than 1 instance of my consumer service, is there any solution to this? Thanks a lot!

Edit: Added some code for example

// Stream creation
jsm.streams.add({
  name: 'ocr-analysis',
  subjects: [
    'ocr.*',
  ],
  retention: RetentionPolicy.Workqueue,
});

// Subscriber creation
const options = natsSubscriptionOpts; // Defined earlier
const subscription = await js.subscribe('ocr.analysis', options);
(async (sub) => {
  for await (const msg of sub) {
    // ...
    msg.ack();
  }
})(subscription);

[aricart]

@ovesco when you have a work queue there’s a restriction that you cannot have consumer definitions that overlap. You can filter the subject, but the filtering must not overlap. So if consumer A filters on ocr.A, you cannot have consumer B filter on ocr.*, you can however do ocr.B.

[derekcollison]

WorkQueue policy tends to pair best with pull based consumers, of which you can have as many apps as needed to bind to that and request new messages.

If you want a push based consumer bound to a distributed queue that is also possible with a retention based stream like a workqueue but less common pattern for that.