ack-wait and dupe-window behavior when used together

[s4iko]

Hi,
I tried some configuration with ack-wait and dupe-window and I'm not sure what exactly should happened, I often get redelivered message even if ack-wait=8m and dupe-window=10m. Is it the expected behavior ?
I was wondering if a message is redelivered every 8m and the duplication window is 10m the message should never be processed twice.

Thx

[MauriceVanVeen]

AckWait and DupeWindow are two different settings that are not related to each other.

DupeWindow is a setting on a stream, which ensures a message with the same identifier can't be published into the stream again within the dupe window.

AckWait is a setting on a consumer, which manages redeliveries of a message if it's sent to your client but it was not acknowledged within the configured wait time.

If you want a message to be delivered only once you could set the MaxDeliver value to 1, or always Ack or Term the message once you get it.
In that case you could leave the DupeWindow and AckWait to their defaults, 2 minutes and 30 seconds respectively.

[s4iko]

In my case, I use some micro-services that read from a stream and write to another. The incoming message is acknowledge once the outgoing message is sent (and ack by Nats). But I often get redelivered messages after ~5-10 minutes and I struggle to understand why exactly.
I'll try to ack just after getting the incoming message to see if it changes the behavior but it is not an acceptable solution in my case because I must not loose any message.
If you have some advice, tool or a nats box command that can help I'll be very grateful (I already tried "nats s info", "nats c info", "nats c report" to compare message sequences and ack floor, and the Grafana Dashboard).

[MauriceVanVeen]

Can you share nats consumer info? How are you fetching messages using the client?
Let's say you explicitly fetch 1 message, process it, send an outgoing message, wait for its ack, then ack the original message, you will not have it redelivered (as expected).

[s4iko]

The result of nats c info:

Information for Consumer MyStream > my-consumer created 2025-03-10T18:38:24Z

Configuration:

                    Name: my-consumer
               Pull Mode: true
          Filter Subject: MyStream.subject
          Deliver Policy: All
              Ack Policy: Explicit
                Ack Wait: 8m0s
           Replay Policy: Instant
         Max Ack Pending: 10,000
       Max Waiting Pulls: 512

Cluster Information:

                    Name: nats
                  Leader: nats-0

State:

  Last Delivered Message: Consumer sequence: 3,083,160 Stream sequence: 15,378,626 Last delivery: 1h3m57s ago
    Acknowledgment Floor: Consumer sequence: 3,083,160 Stream sequence: 15,378,626 Last Ack: 1h3m55s ago
        Outstanding Acks: 0 out of maximum 10,000
    Redelivered Messages: 0
    Unprocessed Messages: 0
           Waiting Pulls: 4 of maximum 512

Actually I use a pull with a batch-size of 100 (may be it is the source of the issue, I though batch pull would improve performances).

May be not very important but just to add some context, I use Quarkus with Nats Jetstream extension (which rely on SmallRye Reactive Messaging).

And a bit more context, the streams:

│ Stream4            │ File    │ tags: nats-3 │         0 │ 96,945   │ 156 MiB │ 0    │       0 │ nats-3*  │
│ Stream3            │ File    │ tags: nats-2 │         1 │ 111,565  │ 174 MiB │ 0    │       0 │ nats-2*  │
│ Stream2            │ File    │ tags: nats-1 │         1 │ 137,200  │ 207 MiB │ 0    │       0 │ nats-1*  │
│ Stream1            │ File    │ tags: nats-0 │         1 │ 160,673  │ 208 MiB │ 0    │       0 │ nats-0*  │

Stream1 as a dupe-window of 12h, the other a dupe-window of 10m.
There is no replication (replication=1).

The Nats servers are deployed on K8S using the Helm chart and are configured with 2 CPU (=2 cores) and 2Go of RAM.

Thx

[s4iko]

Can you share nats consumer info? How are you fetching messages using the client? Let's say you explicitly fetch 1 message, process it, send an outgoing message, wait for its ack, then ack the original message, you will not have it redelivered (as expected).

put me on the right path thanks.

The problem was due to the use of a batch-size of 100. I removed this parameter and there were no more message were redelivered.
I don't know if a lower may work... but processing messages 1 by 1, as you mention, on the whole process is probably the less error prone way to do this.

Sorry for having bothered you for this.
Thanks again for the help :)