3

As seen below, I have a subscription set to retry 5 times and them move the message to a deadlettering queue. I also have the retry policy set to exponentially back off. This is however not happening. All the config was done using the web console interface.

enter image description here

Is there any reason this is not working? All the above settings seem to just be ignored. Still seems to retry immediately and continuously.

Chognificent
  • 393
  • 6
  • 20
  • Can you share some example code? Are you actually nacking the same message? Are you maybe have other messages at the same time being consumed? – tclass May 23 '21 at 18:34
  • Not creating the deadletter topic using code. Creating it from the web-console. I am dropping 1 problematic message which should be moved to the deadletter after 5 retries, but for some reason, it doesn't. – Chognificent May 24 '21 at 07:24
  • We have the same problem, did you find a solution? – Sytten Jan 29 '22 at 14:00
  • @Sytten, unfortunately no. – Chognificent Jan 30 '22 at 15:12
  • OK well I think I found the problem. The idea is that the maximum backoff is not used in the "exponential" back calculation, only the minimum is. So if you have 5 retries with a minimum of 20s, you will likely get something like 20, 23,25,28,30 of backoff. I mistook that for a failure to retry but in reality it is just their calculation that is very weird (they don't even publish the constant used). The max is only used to cap the output of their calculation. So what we did is increase the minimum backoff to 2m and the number of retries to 10 so we know that it will retry for at least 20m. – Sytten Jan 31 '22 at 16:45

1 Answers1

0

For me, this was because the Pub/Sub service account didn't have permissions. Once they were granted, problem messages were moved to Dead Letters after the specified number of max retries.

Check the Dead Lettering tab for the Subscription:

enter image description here

Appetere
  • 6,003
  • 7
  • 35
  • 46