[FIXED] Don't report redeliveries for consumer with MaxDeliver 1

[MauriceVanVeen]

A consumer with MaxDeliver: 1 reports non-acked messages as Redelivered Messages, although no redeliveries have happened. The state is still preserved, otherwise unacked messages in an Interest stream can be lost if used for DLQ (#6538). But we don't report redeliveries anymore for this case.

Resolves #6874

Signed-off-by: Maurice van Veen [email protected]

[ro0NL]

im wondering if the server can expose both numbers (currently our app interpreters 'redeliveries' as 'pending messages/acks')

[MauriceVanVeen]

im wondering if the server can expose both numbers (currently our app interpreters 'redeliveries' as 'pending messages/acks')

The server already exposes that through NumPending, which is the pending (not delivered yet) messages, andNumAckPending, the messages that are waiting for acks.

[ro0NL]

Im not seeing it in nats schema info io.nats.jetstream.api.v1.stream_info_response

However, it does confirm stream.info.state.messages is the current no. of messages stored in the queue:

              "properties": {
                "messages": {
                  "description": "Number of messages stored in the Stream",

in our case this exposes 10 (redelivered, 0 as per this PR, but we seek the no. of pending acks generally).

[MauriceVanVeen]

That is stream info, not consumer info:

nats schema info io.nats.jetstream.api.v1.consumer_info_response

[ro0NL]

We need to indeed use the consumer info 👍 fixed on our side also.

I dont understand the difference between NumPending and NumAckPending quite yet, in our case we see:

        Outstanding Acks: 0
    Redelivered Messages: 0
    Unprocessed Messages: 2

given 2 dispatches. When we ack 1, we see:

        Outstanding Acks: 0
    Redelivered Messages: 0
    Unprocessed Messages: 1

[MauriceVanVeen]

@ro0NL, Let's take this discussion out of this PR and back into the issue: #6874 (comment)

[neilalexander]

LGTM