Should be possible to nack a message for delayed redelivery

[mgabeler-lee-6rs]

Environment details

• OS: any
• Node.js version: any
• npm version: any
• @google-cloud/pubsub version: current

Steps to reproduce

1. Receive a message
2. Decide that the message cannot be processed yet
3. Don't want to block flow control by delaying before nacking
4. Find yourself frustrated

This is something I'd been looking for for my application, but also came across in #119 (comment)

The suggestion there of adding an optional delay parameter to the nack method looks like exactly the trick.

Intending to file a PR for this unless I receive objections to the idea.

[mattxgreen]

I had this issue as well, but just add a delay to the nack, and increase concurrency. 😐

[mgabeler-lee-6rs]

I had this issue as well, but just add a delay to the nack, and increase concurrency.

That's basically what we're doing now, but it does not scale well, at all.

[gae123]

This has been closed with a commit by @JustinBeckwith but unless I am missing something it does not appear to be integrated, what is the status?

[bcoe]

@callmehiphop can you speak to this, we've released quite a few releases of the library since this this landed, is the option just not exposed to users?

[mgabeler-lee-6rs]

This / #256 was reverted in #668

[gae123]

I understand that this was reverted but the need for this remains. Any plans?

[callmehiphop]

My understanding is that the PubSub team is aware that users want this functionality and they're planning something around it, but currently there's nothing on my radar.

[mgabeler-lee-6rs]

Are you referring to ordering, or to delayed retries? There are good reasons for delayed retries that have nothing to do with ordering, as evidenced by Google's on (very good!) recommendations on exponential backoff ... which PubSub doesn't seem to believe in?

[maheshgattani]

You can now configure a retry policy in your Cloud Pub/Sub subscription. Retry policy allows users to have per message exponential backoff in case of failures.

More information can be found here.

[mgabeler-lee-6rs]

To save folks that come here and are about to ask the question I was going to of "how": #1029

From some UTSL: it looks like the basic answer is "use subscription.setMetadata, there is a retryPolicy member in there".

[feywind]

You should be able to configure the retry policy by way of the gcloud utility, as well as the web control panel, and yep - subscription.setMetadata is currently the intended way to do it programmatically.

gcloud pubsub subscriptions update <subname> [--min-retry-delay|--max-retry-delay]

(There are other metadata operations available too, try gcloud pubsub subscriptions update to get the full list.)