unacked messages being redelivered

From @rhodgkins on November 23, 2017 15:19

In previous (I think v0.12 and lower) versions of pubsub messages were auto acked upon receiving a message (or if this was turned off, had to be manually acked). As I understood this had to happen within the ackDeadlineSeconds time and this could be modified with subscription.modifyAckDeadline().

Now the newer version (v0.15), from looking at the code, uses timers to “lease” out the message (using the acDeadlineSeconds time as the initial lease interval), automatically extending the ack deadline until either message.ack() or message.nack() is called? What happens if you don’t do this for a long period of time? Does the lease timer keep on and on extending the ack deadline?

The reason I’m asking for clarification is that I’ve seen unacked (that is neither .ack() or .nack() has been called on the message) messages being delivered again after a period of time.

So the following would happen:

1. Message A published
2. Message A received and not acked or nacked
3. Period of time passes - say 3 mins
4. Message A is received again

I’ve also had it where I’ve nacked a message and the current message I’m processing is delivered again.

1. Message A published
2. Message A received and not acked or nacked
3. Message B published and nacked
4. Message A is received again

I’ll try and post some replication steps for the latter issue (its not consistent when I have seen it), but if anyone can confirm by above questions that would be great! Cheers!

Copied from original issue: GoogleCloudPlatform/google-cloud-node#2756

[callmehiphop]

@rhodgkins thanks for opening this, I need to dig into this a little more, but I think there could be a latency issue where we try and extend the ack deadline but before the request is sent it expires - hence the redelivery.

[rhodgkins]

@kir-titievsky yeh it looks much better just from a brief test! I’ll keep an eye on the test env we’re using it in and report back. Thanks again for your help 🙂