Doesn't NakWithDelay reduce the MaxAckPending counter and block the execution of other messages?

[AlexandrTQ]

Let's say I set MaxAckPending to 10.
Then I used msg.NakWithDelay(time.Minute) ten times and it stopped working. That is, while the message is in the NakWithDelay status, the MaxAckPending counter takes it into account.
I would like to have the behavior that while the message is in the NakWithDelay status, it does not block the queue. While these messages are waiting for a timeout, others are being executed. How can I do this?
Example code:

func TestNats(t *testing.T) {
	opts := nats.Options{
		Servers:        []string{"nats://localhost:4222"},
	}

	conn, err := opts.Connect()
	if err != nil {
		t.Fatalf(err.Error())
	}

	js, err := jetstream.New(conn)
	if err != nil {
		t.Fatalf(err.Error())
	}

	cfg := jetstream.StreamConfig{
		Name:      "StreamName",
		Retention: jetstream.WorkQueuePolicy,
		Subjects:  []string{"subject"},
	}

	stream, err := js.CreateStream(context.TODO(), cfg)
	if err != nil {
		t.Fatalf(err.Error())
	}

	consumerCfg := jetstream.ConsumerConfig{
		Durable:       "subject",
		FilterSubject: "subject",
		MaxAckPending: 10,
		MaxDeliver:    10,
		AckWait:       10* time.Second,
	}

	cons, err := stream.CreateOrUpdateConsumer(context.TODO(), consumerCfg)
	if err != nil {
		t.Fatalf(err.Error())
	}

	var counter int32
	jscontext, err := cons.Consume(func(msg jetstream.Msg) {
		atomic.AddInt32(&counter, 1)
		msg.NakWithDelay(time.Minute)
	})
	if err != nil {
		t.Fatalf(err.Error())
	}

	for i := 0; i < 100; i++ {
		go func() {
			_, err = js.Publish(context.TODO(), "subject", []byte("123"))
			assert.Nil(t, err)
		}()
	}

	_, err = js.Publish(context.TODO(), "subject", []byte("123"))
	if err != nil {
		t.Fatalf(err.Error())
	}

	time.Sleep(time.Second * 2)
	fmt.Println(counter) // 10, want 100

	defer jscontext.Stop()
}

[ripienaar]

Any messages that was once delivered and had to be retried is pending, its an important constraint as max pending is used to manage ordering to name but one case.

So this is working as designed, there's no alternative today

[ripienaar]

With this case you would get a default value for MaxAckPending, in your initial code you set it to 10

[derekcollison]

This would only work if you ran only one copy of your app, but if that is the case I believe you are correct.

[AlexandrTQ]

@derekcollison
Why won't this work with multiple instances of the application? I'm testing now and it seems like the messages are distributed equally to each copy of Consume. That is, if I launch 2 instances of the application, and in one I create 10 copies of Consume, and in the second 2 copies, then 100 messages are divided between them as 84 and 16.
If the number of copies in both is equal, then 50 each.

[derekcollison]

I thought the intent was to still have essentially max ack pending, or inflight, be 10.

[AlexandrTQ]

@derekcollison
Well, can I set the number of copies of Consume in each instance and in total get the required quantity? For example, 5 in each instance of the application =)

[derekcollison]

@derekcollison I thought the same - above was your answer though, that doing that would break ordering etc

@ripienaar let's you and I discuss at some point and see if it makes sense. I agree about ordering but with NAK that has already been violated to some degree based on the observer.